Re: Partial Clone, and a strange slow rev-list call on fetch

From: Tao Klerks <tao@klerks.biz>
Date: Jun 5, 2021, 06:35 UTC
Message-ID: <CAPMMpojV6McG-mc1xwuC0CEY5_E7=PBGQF-ijhb-EP4T=6Qu7w@mail.gmail.com>
In-Reply-To: <5ce5286c-9390-7cb5-a039-8e26be990b8d@gmail.com>

On Fri, Jun 4, 2021 at 3:21 PM Derrick Stolee <stolee@gmail.com> wrote:

Show 6 quoted lines

> You
> have convinced me that there are deeper things going on than just
> the "unshallow, but with filters this time" situation.
>
> I have created an internal issue for my team to investigate this
> when we have capacity for it.

Awesome, thanks!

One more comment on this: As I was trawling through release notes looking for the right minimum git client version to target/support, I discovered that the whole "fetch shallow, then unshallow filtered" flow, which I might have thought I came up with on my own, was intended to be supported with a change Xin Li made about a year ago, and landed in 2.28.0: https://github.com/git/git/commit/01bbbbd9daaa277a95ae46e5a32f6fba026610ac.

As far as I can tell this implementation/behavior does *not* attempt to convert existing non-promisor packfiles to promisor packfiles, so either this behavior should be adjusted to do so, or we should consider this flow (and the presence of non-promisor packfiles at the "tip") supported...?