Re: Pull is Mostly Evil

From: Max Kirillov <max@max630.net>
Date: May 7, 2014, 22:37 UTC
Message-ID: <20140507223752.GA13933@wheezy.local>
In-Reply-To: <5364A143.1060404@bbn.com>

Hi.

I might be late to this discussion, but here either something I don't understand or something is missed.

On Sat, May 03, 2014 at 03:56:51AM -0400, Richard Hansen wrote:

Show 18 quoted lines

> In my experience 'git pull' is mostly (only?) used for the following
> three tasks:
> 
>  1. update a local branch to incorporate the latest upstream changes
> 
>     In this case, the local branch (master) is a
>     derivative of the upstream branch (origin/master).
>     The user wants all of the commits in the remote branch
>     to be in the local branch.  And the user would like
>     the local changes, if any, to descend from the tip of
>     the remote branch.
> 
>     For this case, 'git pull --ff-only' followed by 'git
>     rebase -p' works well, as does 'git pull
>     --rebase=preserve' if the user is comfortable rebasing
>     without reviewing the incoming commits first.  A plain
>     'git pull' or 'git pull --ff' is suboptimal due to the
>     awkward backwards-parents merge commit.

This is actually not a finally defined use case. What kind of "local changes" user can have ahead of the remote? As far I understand, there are 3 cases:

 1a. Changes that are going to be merged back to the master,
     but not yet ready to be there.

This is essentially the same as case 2, but it does not name the development branch explicitely. Switching parents for this case is not desirable.

 1b. Some truly local changes which never goes anywhere.

For this case the parent order does not matter.

 1c. The local changes prepared for integration, but instead
     of filing a pull request of otherwise publishing the
     branch for integrator, the leaf developer does the
     integrator's job and merges it back to master and then
     publishing the master.

As far as I understand, this is the only case when somebody would want the parents to be switched. And this does not seem to be a good practice, because it's prone to push races and requires letting everyone to push to master. So maybe git should not encourage people to do so.

And the name "update", proposed here, does not seem to be correct. Because what happens is not updating, but merging feature to master and closing it.

>  2. update a published feature branch with the latest
>     changes from its parent branch

>  3. integrate a more-or-less complete feature/fix back
>     into the line of development it forked off of

-- 
Max