Re: Git 2.36, ls-tree submodule regression?

From: Teng Long <dyroneteng@gmail.com>
To: bturner@atlassian.com
Cc: avarab@gmail.com, dyroneteng@gmail.com, git@vger.kernel.org
Subject: Re: Git 2.36, ls-tree submodule regression?
Date: Thu,  7 Apr 2022 10:22:07 +0800	[thread overview]
Message-ID: <20220407022207.12542-1-dyroneteng@gmail.com> (raw)
In-Reply-To: <CAGyf7-FjqrGYTUwdS=a6nsUnbn0qD9=Pf2Nx=gy6g8KGVRJivw@mail.gmail.com>

> 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]

> 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/