git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philippe Blain <levraiphilippeblain@gmail.com>
To: "Yngve N. Pettersen" <yngve@vivaldi.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Git fetch failure in submodule if deeper submodule pointer updated
Date: Sun, 20 Dec 2020 20:08:47 -0500	[thread overview]
Message-ID: <d1fcf5ed-9dea-9721-55da-a3d85a9916d8@gmail.com> (raw)
In-Reply-To: <op.0vvmwohypvqxoc@damia>

Hello Yngve,

Le 2020-12-19 à 09:37, Yngve N. Pettersen a écrit :
> Hello all,
> 
> Recently we encountered a git fetch issue similar to the one I have reported earlier, <https://marc.info/?l=git&m=158979416620251&w=2>, which AFAICT has not yet been fixed.

Regarding your earlier report, I don't think it has been fixed either.
The fact is that I don't think any full-time contributor to Git works
on submodules much these days, so issues like this one, that need design-level
discussions to be fixed, often take more time to get fixed, if they ever are.
Now on to your new report:

> 
> In this case we had checked out a submodule, but not the submodule(s) below it.
> 
> The full submodule chain was like this:
> 
>    top->middle->bottom
> 
> The actual checkout was
> 
>    top->middle
> 
> Because only "middle" was needed for the cron job script used to push updates to "top" and "middle", "bottom" was never checked out (and it should not be necessary to do so, either).
> 
> When the pointer to "bottom" was recently updated in "middle", the cron job failed, because Git "could not access submodule bottom".
> 
> As I said in my earlier report, this kind of issues should, at most, only trigger a warning, not a fatal error.
> 
> 
> The Git version on the system is Git v2.25.1 (Ubuntu 20.4)
> 
> This problem is not occuring in Git v2.17 on Windows.
> 
> Attached is a zipfile with a script that reproduces the problem.

Thanks for the report and the reproducer. This bug was in fact reported and fixed
earlier this month [1] (full threads: [2], [3]). The patch series is currently cooking
in the 'next' branch [4]. You can check out just the fix from [5]. I don't think
it's going to make it to Git 2.30, but it should be in 2.31.

Cheers,

Philippe.

[1] https://lore.kernel.org/git/20201209105844.7019-1-peter.kaestle@nokia.com/
[2] https://lore.kernel.org/git/CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@mail.gmail.com/t/#u
[3] https://lore.kernel.org/git/1604413399-63090-1-git-send-email-peter.kaestle@nokia.com/t/#u
[4] https://github.com/git/git/blob/730f2a8a60960c30a79e00ebe034836f60befbf0/whats-cooking.txt#L765-L771
[5] https://github.com/gitster/git/tree/pk/subsub-fetch-fix-take-2

      reply	other threads:[~2020-12-21  4:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-19 14:37 Git fetch failure in submodule if deeper submodule pointer updated Yngve N. Pettersen
2020-12-21  1:08 ` Philippe Blain [this message]

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=d1fcf5ed-9dea-9721-55da-a3d85a9916d8@gmail.com \
    --to=levraiphilippeblain@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=yngve@vivaldi.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;
as well as URLs for NNTP newsgroup(s).