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

Sebastian Schuberth <sschuberth@gmail.com> writes:

Good point. "We will try but it might fail" is better left unsaid as that is true almost everywhere.

Hmm, is this line-wrapped?

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?

This reminds me a related tangent discussion we had long time ago (I thought j6t was involved hence a new Cc:, but my apologies to j6t if I am misremembering), about what exactly is "recreate merges instead of replaying commits".

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

Surely there is no such mode right now, but I am fairly sure that I wouldn't have any objection against a patch to implement such a feature (perhaps "--first-parent --preserve-merges"?), and with or 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".