Re: [PATCH/RFC] rebase -p: do not redo the merge, but cherry-pick first-parent changes

> 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'.

> 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.