Re: [PATCH v4 04/11] commit-reach(paint_down_to_common): prepare for handling shallow commits

From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Patrick Steinhardt <ps@pks.im>,
	 Dirk Gouders <dirk@gouders.net>,
	 Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v4 04/11] commit-reach(paint_down_to_common): prepare for handling shallow commits
Date: Wed, 28 Feb 2024 12:24:59 -0800	[thread overview]
Message-ID: <xmqqedcwjq04.fsf@gitster.g> (raw)
In-Reply-To: <837aa5a89c640427a5de064da93f1de4934d8212.1709113458.git.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Wed, 28 Feb 2024 09:44:10 +0000")

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When `git fetch --update-shallow` needs to test for commit ancestry, it
> can naturally run into a missing object (e.g. if it is a parent of a
> shallow commit). For the purpose of `--update-shallow`, this needs to be
> treated as if the child commit did not even have that parent, i.e. the
> commit history needs to be clamped.
>
> For all other scenarios, clamping the commit history is actually a bug,
> as it would hide repository corruption (for an analysis regarding
> shallow and partial clones, see the analysis further down).
>
> Add a flag to optionally ask the function to ignore missing commits, as
> `--update-shallow` needs it to, while detecting missing objects as a
> repository corruption error by default.
>
> This flag is needed, and cannot replaced by `is_repository_shallow()` to
> indicate that situation, because that function would return 0 in the
> `--update-shallow` scenario: There is not actually a `shallow` file in
> that scenario, as demonstrated e.g. by t5537.10 ("add new shallow root
> with receive.updateshallow on") and t5538.4 ("add new shallow root with
> receive.updateshallow on").

Nicely written.

The description above that has been totally revamped reads much much
clearer, at least to me, compared to the previous round.  

Should we declare the topic done and mark it for 'next'?

Thanks.