Re: Pull is Evil

From: Marc Branchaud <marcnarc@xiplink.com>
Date: May 1, 2014, 15:20 UTC
Message-ID: <5362664C.8040907@xiplink.com>
In-Reply-To: <20140501094610.GB75770@vauxhall.crustytoothpaste.net>

On 14-05-01 05:46 AM, brian m. carlson wrote:

Show 26 quoted lines

> On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
>> Marc Branchaud wrote:
>>> On 14-04-30 04:14 PM, Felipe Contreras wrote:
>>>> What is wrong when `git pull` merges a fast-forward?
>>>
>>> Nothing.  Everything.  It depends.
>>
>> It depends on what? I don't see how a fast-forward `git pull` could
>> possibly have any trouble.
>>
>>>> The problems with `git pull` come when you can't do a fast-forward merge, right?
>>>
>>> Some of them, maybe most of them.
>>
>> Name one problem with a fast-forward merge.
> 
> At work, we have a workflow where we merge topic branches as
> non-fast-forward, so that we have a record of the history (including who
> reviewed the code), but when we want to just update our local branches,
> we always want fast-forward:
> 
>   git checkout maintenance-branch
>   # Update our maintenance branch to the latest from the main repo.
>   git pull --ff-only
>   git pull --no-ff developer-remote topic-branch
>   git push main-repo HEAD

Thanks for the nice example.

To me this looks like an advanced use of "git pull". A new user could be taught to work like this, but I don't think a new user would come up with it on their own (until they became an experienced user).

What's more, it seems to me that the only real advantage "git pull" provides here is a less typing compared to the non-pull equivalent:

  git fetch main-repo
  git checkout main-repo/maintenance-branch
  git fetch developer-remote
  git merge --no-ff developer-remote/topic-branch
  git push main-repo HEAD

I suggest that this approach is superior for new users (despite the increased risk of finger cramps), because if main-repo's maintenance-branch is updated in the interim and the push fails, the user can use the exact same commands to resolve the situation.

Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and namespaces and detached HEADs -- oh my!). But trying to avoid that stuff is precisely the slippery slope that led to pull's misguided gymnastics. We've gone down that slope, slipped and fallen over, and now we're wallowing in the muck.

M.