Re: [PATCH v2 3/3] replay: offer an option to linearize the commit topology

From: Toon Claes <toon@iotcl.com>
Date: Jun 16, 2026, 08:38 UTC
Message-ID: <871pe6zxpx.fsf@emacs.iotcl.com>
In-Reply-To: <xmqqjys6wcpo.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> In the review response during the previous iteration, I commented
> that (1) the original excluded only merges, but (2) your version
> excluded both merges and the root commits the same way.  Your
> response was:
>
>     The way it was written in v1 was maybe a bit too smart and hard to
>     follow. I agree with your suggestion and will adopt this (with some
>     tweaks) in the next version.
>
> which I took as saying "it may be confusing, but it correctly
> expresses what we want to do", meaning "yes, roots and merges should
> be handled the same way".  But the above no longer treats roots the
> same way as merges.  I think that is intended, but just wanted to
> double check.

Great callout. I was running the "replay down to root" test with v1 vs v2, but as you pointed out, the test I wrote doesn't actually replay down to root. Now I've fixed the test and reran the test against both versions and verified what you're saying.

So to answer your question, yes this change is intentional and shout out to you for requesting to add this test (properly) so we actually catch this.

Show 7 quoted lines

>> +test_expect_success 'replay to rebase merge commit with --linearize down to root commit' '
>> +	git replay --ref-action=print --linearize --onto main A..topic-with-merge >result &&
>
> As with other test pieces, this "git replay" command line is overly
> long and hides the important bit which is that the range being
> replayed is *not* actually down to the root, which is A (it excludes
> A).  Intended?

No, not intended. And while at it, I'll split up the command on two lines.

-- 
Cheers,
Toon