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

Toon Claes [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

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.