Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does
- From
Sergey Organov <sorganov@gmail.com>
- Date
- Mar 31, 2015, 09:13 UTC
- Message-ID
- <87lhidlebw.fsf@javad.com>
- In-Reply-To
- <55147D27.1060204@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
>> Junio C Hamano <gitster@pobox.com> writes:
[...]
Show 11 quoted lines
> 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.