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