Re: Pull is Mostly Evil

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 6, 2014, 22:19 UTC
Message-ID: <53695ff6b1535_747f1521308c5@nysa.notmuch>
In-Reply-To: <xmqqy4yed0jq.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:

Show 11 quoted lines

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

Show 5 quoted lines

>    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