Junio C Hamano wrote:
> But recording the merge to have parents <Z C> does not give us
> "the first-parent is the trunk" worldview, in the presense of B.
> We would prefer to end up with a history more like this:
> -----A ----O
> \ \
> so that your work, your contribution with two commits of yours,
> was to merge the work done on a side branch and then made one
> commit directly on top of it.
Yes, _ideally_, but as it has been explained multiple times most Git
beginners have no idea what is a rebase.
We might evenaully do this by default, but first we should start
rejecting the update by default and recommending `git update --merge` as
it has been discussed quite a lot should be the behavior of `git pull`.
> Hence, I think the ideal behaviour of the new command is to
> replay the first-parent history on top of the updated tip of your
> upstream (which by the way is different from how "rebase
> --preserve-merges" works; it is more like how J6t wanted to make
> "rebase --preserve-merges" work, IIRC).
What is the difference with 'rebase -p'?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html