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
>           \           \
>            X---Y---Z---B'--C'
>    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'?

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

Reply via email to