Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

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

 



Johannes Sixt <j6t@xxxxxxxx> writes:

>> Junio C Hamano <gitster@xxxxxxxxx> writes:

[...]

> The patch was discussed here:
> http://thread.gmane.org/gmane.comp.version-control.git/198125
>
> The reason that this has not progressed any further is this response
> in the thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198483
>
> where you basically say that a --first-parent mode is good, but it
> should be separate from --preserve-merges. I haven't made up my mind,
> yet, how to proceed from there.

As far as I can see, there are 2 separate issues:

1. How to calculate the set of commits to rebase.

2. How to rebase merge commits.

Can we leave (1) for a while at its current state and focus on (2)?
Johannes's patch contains a fix for that: use cherry-pick to recreate
merge commits instead of trying to re-merge. Could this change be
accepted alone, as a known fix for current buggy behavior of loosing
user changes in merge commits?

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