Re: [PATCH] bootstrap: When a commit hash is specified, do a shallow fetch if possible

[Glenn Washburn <development@efficientek.com>]

On Mon, 25 Oct 2021 23:35:06 +0200
Daniel Kiper <daniel.kiper@oracle.com> wrote:

> On Fri, Oct 22, 2021 at 04:26:41PM -0500, Glenn Washburn wrote:
> > On Fri, 22 Oct 2021 18:44:15 +0200
> > Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > Is this hunk from gnulib upstream? If not I would prefer if you upstream
> > > it into gnulib. We should avoid custom patches for imported code as much
> > > as possible.
> >
> > I agree in general. As mentioned in a follow up reply to this patch, I
> > did submit the patch upstream[1]. The only difference is the commit
> 
> Oh, sorry, I missed this somehow.
> 
> > message. It has not been responded to yet. However, even once accepted
> > upstream we'll have to cherry-pick it to the GRUB repo. Are you
> > thinking we'd need to get all changes to bootstrap at that time? It
> > doesn't look like there's anything that would be that useful (except
> > maybe using the https repo url). I'm curious how you'd like to handle
> > this.
> 
> I want to bump the gnulib version to the latest one. Though first of all
> we have to upstream a few gnulib issues discovered by the Coverity.
> Darren, CC-ed, is working on it.

What's the current status of this?

> > I don't think the issue of a custom patch in this instance is a problem
> > though. Bootstrap very rarely changes, even in upstream (<10 changes in
> > the last 2 years). So there I'm not concerned about having to maintain
> > a lot of custom patches on top of it (like the situation of many
> > distros vis-a-vis GRUB). So I think if its not accepted upstream (I
> > don't see why it wouldn't be), I think we should use in GRUB because it
> > provides significant reduction in bandwith and a drastic reduction in
> > time to checkout on a qemu VM (but also significant not on a VM, 5min
> > vs 1min) depending on the CPU resources available. This is especially
> > useful for a CI/testing system that is frequently run.
> 
> If gnulib upstream folks reject it then I can consider taking this patch
> into the GRUB.
> 
> > I'm fine with waiting a few weeks and see what happens upstream.
> 
> Sounds like a plan.
> 
> Daniel
> 
> > Glenn
> >
> > [1] https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00052.html

Ok its finally been committed to the upstream repo after being missed
these past few months. Once/if the Coverity issues are committed we can
work on using the latest git revision.

Glenn