[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v4 04/11] commit-reach(paint_down_to_common): prepare for handling shallow commits
From:       Johannes Schindelin <Johannes.Schindelin () gmx ! de>
Date:       2024-02-29 9:54:25
Message-ID: 7552da7e-2aa3-73bc-2e55-304b09f280f8 () gmx ! de
[Download RAW message or body]

Hi Dirk,

On Wed, 28 Feb 2024, Dirk Gouders wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
> > "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. th=
e
> >> commit history needs to be clamped.
> >>
> >> For all other scenarios, clamping the commit history is actually a bu=
g,
> >> 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 i=
n
> >> that scenario, as demonstrated e.g. by t5537.10 ("add new shallow roo=
t
> >> with receive.updateshallow on") and t5538.4 ("add new shallow root wi=
th
> >> 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.
>
> I agree that this text reads much clearer -- even to me with close to
> zero experience, here.
>
> Thank you for taking the time to rewrite the text, Johannes.

Thank _you_ for taking the time to review the patches and help me with
improving them!

Ciao,
Johannes

[prev in list] [next in list] [prev in thread] [next in thread]