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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2026, 19:35 UTC
Message-ID: <xmqqy0fm1tkc.fsf@gitster.g>
In-Reply-To: <87ldbm3kh6.fsf@emacs.iotcl.com>

Toon Claes <toon@iotcl.com> writes:

Show 24 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Definitely it is OK to leave it outside the scope, but I am not sure
>> if reverting a group of commits that happens to be "closed" and
>> happens to contain merges, is inherently incompatible with
>> flattening.  If you have
>>
>>     ----O--A
>>          \  \
>>           B--M--C
>>
>> and you want to revert what happened while the history advanced from
>> O to M, I would naïvely expect that I can arrive at
>>
>>     ----O--A
>>          \  \
>>           B--M--C-B'-A'
>>
>> by linearly applying the inverse of A and B (in either order).
>
> You're absolutely right. Personally I'm not sure why the limitation was
> introduced. I've done some testing and I cannot see why we wouldn't
> allow --revert and --linearize to be combined. So I'll be submitting v7
> without this restriction.

Of course, postponing this is a safe option (at least for our initial effort) *if* we cannot reliably detect the good case.

For example, it is unclear what happens if the linearized range in the diagram above contains M and A, but not B or O. We might want to distinguish that scenario from the depicted case, where all of A, B, and O, as well as M, are in the range, but the current code may not be able to do so reliably. However, if we can consistently provide behavior that is logical and easy to explain, it would be ideal to lift this artificial restriction.

Thanks.