Re: [lmi] Transient git error

[Greg Chicares]

On 3/23/23 11:29, Vadim Zeitlin wrote:
> On Wed, 22 Mar 2023 23:16:33 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 3/22/23 22:43, Vadim Zeitlin wrote:
> GC> > On Wed, 22 Mar 2023 21:09:53 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> GC> > 
> GC> > GC> In a freshly-built chroot, 'git fetch --all' initially failed as
> GC> > GC> follows...
> GC> > GC> 
> GC> > GC> Could not access submodule '3rdparty/wxWidgets' at commit 938b8a6ae
> GC> > GC> Could not access submodule '3rdparty/wxpdfdoc' at commit 8752a7da6
> GC> > GC> Could not access submodule '3rdparty/xmlwrapp' at commit 8752a7da6
> GC> > 
> GC> >  I guess it was a bad idea to push my "tt" branch containing these 
> commits,
> GC> > which reference my own old submodules (predating the ones under
> GC> > third_party) to GitHub. It's convenient for me, but I can live without 
> it
> GC> > and delete it from there. Should I do it?

Not needed, thanks.

> GC> To answer that, first we must ascertain whether any actual
> GC> problem exists in practice
> 
>  This depends on your definition of "a problem". I.e. are the messages
> above "a problem" or not?

They're not a problem in practice: the only thing that really matters
is getting the repository to the right SHA1. We can do that with:

  git fetch --all
  [ignore the non-fatal "fatal" errors documented earlier in this thread]
  git fetch --all

If you were to alter your repository, we could replace that with:

  git fetch --all

but that's not worth the trouble.

> I'd actually argue that they're, because they
> definitely seem scary, but OTOH if they really only appear once, maybe it's
> not too bad.

Exactly.

> Especially if you can avoid seeing them in automatic scripts
> by using git-fetch --depth option to create a shallow clone, because I'm
> almost sure that doing this wouldn't fetch these commits at all -- and also
> should be significantly faster, so could be well worth doing in any case.

This is one of the few things that no lmi script does--fetching:
  git grep 'git.*fetch'
is done only manually, to make sure it's always intentional.

There must be other scripted operations (git-clone, probably)
that could be made faster with '--depth', but I don't think the
benefit could be worth the effort.

>  So, to summarize, I won't argue very strongly and if you think these
> messages are not a problem, I certainly don't mind. And I don't think there
> are any other problems, but please let me know if you run into any, of
> course.

The tests I've run so far have found no problem with these upgrades.