From: Sebastian Schuberth Date: Thu, 26 Mar 2015 20:28:37 GMT Subject: Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does Message-ID: <55146BF5.7040008@gmail.com> In-Reply-To: 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 > and 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 and > ", 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