Re: Pull is Evil

[Andreas Krey <a.krey@gmx.de>]

On Thu, 01 May 2014 16:21:42 +0000, Marc Branchaud wrote:
...
> 
> But these days there's hardly any risk to using a detached HEAD.  Plus
> nowadays I think it's commonly accepted that using topic branches is a git
> best practice.  The notion of doing work on a generically-named branch like
> "maint" seems archaic.
> 
> So what benefit does "git pull" provide?

It provides the moral equivalent of 'cvs update', 'svn update', and
'clearcase <do nothing>'.

Even when I'm on a feature branch, there are cases where I have that branch
as the current one in multiple repos (on different machines because testing),
or multiple people working on that branch. A 'git pull' is the obvious way
to get divergent branches back together.

In cvs&svn a local workspace can't ever be more than half a commit ahead,
and what an 'update' does is most similar to a rebase in git. But I'm
not eager to teach this future userbase rebases, and also a rebase loses
expensive test results that are tied to the commit ids.

My personal beef with 'git pull' is still that sometimes (namely in the
'git pull && git push' sequence) it should reverse the order of the
parents in the merge commit, so that *my* commits look like an
integrated topic branch, instead of the former mainline.

Unfortunately the answers to the question "what to do instead of 'git
pull'" are, in increasing order of teaching needed:

- Ok, just 'git pull' <sigh>.

- Please do a 'git pull --rebase'; I'll show you how.

- <Something involving switching branches and doing the
   merge in the other direction>

(I'm coming from a 'blessed repo where everybody pushes to' setup,
and we're considering a server trigger that refuses pushes where
the previous head is not a *first* parent of the new head, in order
not to accidentally mess up the mainline.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800