git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git 2.36, ls-tree submodule regression?

From
Teng Long <dyroneteng@gmail.com>
Date
Apr 7, 2022, 02:22 UTC
Message-ID
<20220407022207.12542-1-dyroneteng@gmail.com>
In-Reply-To
<CAGyf7-FjqrGYTUwdS=a6nsUnbn0qD9=Pf2Nx=gy6g8KGVRJivw@mail.gmail.com>
Show 27 quoted lines
> Bisecting the error selects:
> 
> $ git bisect good
> 9c4d58ff2c385f49585197c8650356955e1fa02e is the first bad commit
> commit 9c4d58ff2c385f49585197c8650356955e1fa02e
> Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Date:   Wed Mar 23 17:13:15 2022 +0800
> 
>     ls-tree: split up "fast path" callbacks
> 
>     Make the various if/else in the callbacks for the "fast path" a lot
>     easier to read by just using common functions for the parts that are
>     common, and have per-format callbacks for those parts that are
>     different.
> 
>     Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>     Signed-off-by: Teng Long <dyroneteng@gmail.com>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
>  builtin/ls-tree.c | 199 ++++++++++++++++++++++++++++++++++--------------------
>  1 file changed, 125 insertions(+), 74 deletions(-)
> 
> (I've CC'd Ævar and Teng on this message.)
> 
> Looking at the changes in that commit I see differences in the
> handling for long listings, so I tried removing the -l. At that point,
> the command works again:
Yes, it's a bug but already found and fixed by Ævar Arnfjörð Bjarmason.
> Given the command works without -l, and all -l is supposed to do is
> add sizes to blobs, it seems like something has regressed in the logic
> that decides whether to continue recursing or move on to the next
> sibling?
As you described blow, I almost comfirmed it's the problem that
found in [1] and Junio C Hamano already replied it in [2]
 
Show 7 quoted lines
> Can someone else whose C is a little less rusty check this and see if
> it's a bug? It almost seems like it _has_ to be, though. Bitbucket
> Server manages bare repositories which often include submodules, but
> none of those submodules (even assuming they're valid, which is not
> always the case for repositories in the wild) are ever _fetched_ into
> that bare repository. That implies this would always fail in any
> repository that contains submodules referencing other repositories.
Sorry for the trouble.
Thank you for debugging this and reporting this problem. 
Links:
  1. https://public-inbox.org/git/YktP0LltNKq7JZZs@google.com/
  2. https://public-inbox.org/git/xmqq8rsi1ap4.fsf@gitster.g/
Previous: Bryan TurnerNext: Johannes Schindelin
Message 4 of 6 in “Git 2.36, ls-tree submodule regression?”
  1. Bryan TurnerApr 7, 2022
  2. Bryan TurnerApr 7, 2022
  3. Bryan TurnerApr 7, 2022
  4. Teng LongApr 7, 2022
  5. Johannes SchindelinApr 7, 2022
  6. Junio C HamanoApr 7, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.