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

[Johannes Sixt <j6t@kdbg.org>]

Am 26.03.2015 um 22:17 schrieb Sergey Organov:
> Junio C Hamano <gitster@pobox.com> writes:
>> There however were repeated wishes (or wishful misunderstandings ;-)
>> that there were a mode to rebuild the trunk, considering only the
>> commits on the first-parent chain as "commits to be rebased",
>> recreating the history by replaying the merge commits (whose first
>> parent might be rewritten during the rebase, but the tips of side
>> branches these merges bring into the history are kept intact).
>>
>> Surely there is no such mode right now,
>
> Isn't it what Johannes Sixt <j6t@kdbg.org> mentions here?:
>
> [QUOTE]
> If you want a version of --preserve-merges that does what *you* need,
> consider this commit:
>
>    git://repo.or.cz/git/mingw/j6t.git rebase-p-first-parent
>
> Use it like this:
>
>    git rebase -i -p --first-parent ...
>
> Beware, its implementation is incomplete: if the rebase is interrupted,
> then 'git rebase --continue' behaves as if --first-parent were not given.
> [/QUOTE].
>
> ref: http://permalink.gmane.org/gmane.comp.version-control.git/263584
>
> If so, then I'd say such mode almost exists.

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.

If somebody wants to pick up the baton, I'll happily pass it on.

-- Hannes