Hi Bruno,

On Wed, 05 Jan 2022 11:50:13 +0100
Bruno Haible <[email protected]> wrote:

> Hi Glenn,
> 
> In this thread, on 2021-10-24 I replied:
> > > I'm thinking of replacing the current comment with
> > > something along the lines of:
> > > 
> > >   Git does not support cloning by commit hash. So attempt a shallow
> > >   fetch by commit hash to minimize the amount of data downloaded and
> > >   changes needed to be processed, which can drastically reduce download
> > >   and processing time for checkout. If the fetch by commit fails, a
> > >   shallow fetch can not be performed because we do not know what the
> > >   depth of the commit is without fetching all commits. So fallback to
> > >   fetching all commits.
> > 
> > That's a good comment. Thanks.
> 
> There's no other objection to your patch. Can you repost it, with the
> comment added? Then it can go in, I would say.
> 
> Simon explained that there is a Gitlab specific workaround to the
> problem. But IMO if we have a general one that works also on Savannah,
> GitHub, etc., the better.

As I understand it, Simon's issue is also slightly different that the
one this patch addresses because he's using gnulib as a git submodule,
this patch is not for these kinds of setups. Also, I don't think his
solution gets rid of the initial overhead, its basically just a caching
scheme.

I posted a v2 of the patch back in October with the requested comment
above. I'm guessing it got missed. If you still want me to repost the
v2 patch please let me know.

Glenn

[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00073.html

Reply via email to