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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:

> On Mon, May 21, 2012 at 1:19 PM, Johannes Sixt <j6t@xxxxxxxx> wrote:
>> Replace the 'git merge' by a cherry-pick that picks the changes that the
>> merge introduces with respect to the first parent.
>
> Just a reminder of what I said in [1] (the same thread that you referenced):
>
> I think this will break "git rebase -p --onto g b f" on  the below history.
>
>           .-e-.
>          /     \
>       .-c---d---f
>      /
> a---b---g


... where the replayed history would look like this:

                  .-e'.
                 /     \
    a---b---g---c'--d'--f'

and e' and e, even though being "moral equivalent", may have different
degrees of change since c' and c respectively depending on how changes
between b and c and changes between b and g are related to each other.

If the change in the dag b..f does not have much to do with the change
between b and g, then the change from c to e would be the same as the
change from c' to e', and if the original merge at f resolved conflicts
between e and d (or added an evil change), replaying the difference from e
to f on top of e' may give a better result.

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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]