On 14-05-01 05:46 AM, brian m. carlson wrote: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html