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

[Sebastian Schuberth <sschuberth@gmail.com>]

On 26.03.2015 19:18, Junio C Hamano wrote:

>> Also, do not say that merge commits are *tried* to be recreated.
>
> Good point.  "We will try but it might fail" is better left unsaid
> as that is true almost everywhere.

Exactly.

>>   -p::
>>   --preserve-merges::
>> -    Instead of ignoring merges, try to recreate them.
>> +    Recreate merge commits instead of replaying commits a merge
>> commit introduces.
>
> Hmm, is this line-wrapped?

Probably, I had to send this via GMail.

> Although I fully agree that the new text is better than the original,
> I think the new text fails to point out one major aspect by not
> mentioning "linear" or "flatten" anywhere.  The point of "git rebase"
> without "-p" is not just to replay but to flatten
>
> 	Instead of flattening the history by replaying each
> 	non-merge commit to be rebased, preserve the shape of the
> 	rebased history by recreating merge commits as well.
>
> or something along that line, perhaps?

Hm, I'm not sure about the "as well" here. Non-merge commits basically 
are just picked, not recreated in the same sense as merge commits. I'll 
come up with another proposal.

> I think the current preserve-merges considers everything between
> <upstream> and <branch> as "commits to be rebased", and recreate
> merges across these rebased tips of branches that are merged.  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).

I guess I'm a victim of that wishful misunderstanding then, as I indeed 
though that's exactly what the current -p is doing. Well, modulo the 
special case where the second parent is the tip of a branch whose 
fork-point with the trunk is part of the rebase, see "Example 1" at [1].

In other word, you're saying that the current preserve-merges does not 
keep the tips of side branches intact. If that's so, what is is doing 
with the tips of the side branches?

> without such a feature in the system, I would be happier if we made
> sure that the description we are discussing to update makes it clear
> that the current behaviour is "everything between <upstream> and
> <branch>", and cannot be misread as "do not touch side branches
> instead of dropping merged commits".

Agreed. As soon as I understand the difference between the two :-)

[1] http://stackoverflow.com/a/15915431/1127485

-- 
Sebastian Schuberth