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
--
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