From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Wed, 23 May 2012 20:41:17 GMT
Subject: Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes
Message-ID: <CAOeW2eGvEaQYk9KODmLzZuEBu-KhKcQeL4PE-4YHwSgtP0dJfA@mail.gmail.com>
In-Reply-To: <7vzk8yzq35.fsf@alter.siamese.dyndns.org>

On Wed, May 23, 2012 at 11:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I think your original point was that the above clean picture would not
> hold if e-b and g-b has interactions.  g-b may contain some change that
> e-b has independently done, in which case e'-g would be made smaller than
> e-b when the conflict is resolved while replaying e to produce e' on top
> of c' (the same applies if you replace e with any commit in the dag
> "rev-list ^b e d").  The merge to produce f' may result in conflicts,
> whether you merge e' and d' or replay f-e on top of e'.

Right. Or if e' was changed as a result of a "edit" action (I meant to
include '-i' in addition to '-p').

> A better way to keep potential "evil merges" at f while replaying to
> produce f' may *not* be by applying the difference f-e on top of e'.
> Instead, you can learn from what 'rerere' does.  That is, to attempt a
> mechanical merge between e and d and call the result (with possible
> conflict markers and all) pre-f.  If you compare pre-f and f, that is the
> resolution and evil change made at f.  When reproducing f', mechanically
> merge e' and d', call the result (again, with possible conflict markers
> and all) pre-f', and try reproducing f' by a 3-way merge between pre-f,
> pre-f' and f.

Yes, I've had the same idea myself. Anyway, as Johannes said, that's
probably something to consider for the sequencer.

Martin