From: David Aguilar <davvid@gmail.com>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: Toon Claes <toon@iotcl.com>, git@vger.kernel.org
Subject: Re: Shallow clone of a specific git revision?
Date: Thu, 14 Nov 2024 21:00:43 -0800 [thread overview]
Message-ID: <ZzbVe79p_Zbnb6rs@gmail.com> (raw)
In-Reply-To: <ZzR_nOqQxfGNPyYV@kitsune.suse.cz>
On Wed, Nov 13, 2024 at 11:29:48AM +0100, Michal Suchánek wrote:
> On Wed, Nov 13, 2024 at 11:23:47AM +0100, Toon Claes wrote:
> > Michal Suchánek <msuchanek@suse.de> writes:
> >
> > > Hello,
> > >
> > > Looking through clone man page it supports shallow clones of branches
> > > and tags only.
> > >
> > > Would it be possible to do shallow clone of a specific revision,
> > > and checkout specific revision on clone?
> >
> > Hi Michal,
> >
> > I'm working on a patch, and I've submitted a first version [1] a little
> > while ago to allow users to pass a reference on git-clone(1). Would this
> > change fit your needs, or what else would you like to support?
>
> > [1]: https://lore.kernel.org/git/20240927085438.1010431-1-toon@iotcl.com/
>
> Hello,
>
> that slightly expands the available options but it does not make it
> possible to clone an arbitrary revision, ie. specified by a SHA
>
> Thanks
>
> Michal
In case it helps, here's a short recipe demonstrating how to do a
shallow "clone" of a specific commit ID:
git init the-repo
cd ./the-repo
git remote add origin <url>
git fetch --depth=1 origin <commit-id>
git checkout <commit-id>
It'd be nice to add this feature to "git clone" for convenience.
This recipe depends on the server's configuration. You must have one of
the following configuration variables set "true" server-side in order
for the server to accept requests for arbitrary commit IDs:
uploadpack.allowReachableSHA1InWant
Allow upload-pack to accept a fetch request that asks for an
object that is reachable from any ref tip. However, note that
calculating object reachability is computationally expensive.
Defaults to false. Even if this is false, a client may be able
to steal objects via the techniques described in the "SECURITY"
section of the gitnamespaces(7) man page; it’s best to keep
private data in a separate repository.
uploadpack.allowAnySHA1InWant
Allow upload-pack to accept a fetch request that asks for any
object at all. Defaults to false.
cheers,
--
David
next prev parent reply other threads:[~2024-11-15 5:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 12:24 Shallow clone of a specific git revision? Michal Suchánek
2024-11-13 10:23 ` Toon Claes
2024-11-13 10:29 ` Michal Suchánek
2024-11-15 5:00 ` David Aguilar [this message]
2024-11-15 9:37 ` Jeff King
2024-11-15 10:43 ` Michal Suchánek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZzbVe79p_Zbnb6rs@gmail.com \
--to=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=msuchanek@suse.de \
--cc=toon@iotcl.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox