In my previous post I jumped through some hoops to do a “git fetch; git rebase” instead of a “git pull” so that I ended up without a merge commit in my timeline. (See explanation here). Those two commands are very manual, what else can we do?
One simple option is to do git pull --rebase, which rebases instead of merges. However that can apparently cause problems depending on what’s in your local repo. I have no idea what rebase does if there would be a merge conflict.
The git up user-contributed command is another solution. I think at its heart it’s a wrapper for fetch + rebase, but it has some other smarts in it. No idea if it can cause problems.
This StackExchange answer has a much more thorough investigation. He recommends doing a git update followed by git merge --ff-only. I guess fast forwards are “safe”; using this flag prevents git from automatically creating a merge commit if it can’t fast forward. There’s a lot more detail there, worth a close read.
I’m going to follow the StackExchange recommendation of setting git config --global pull.ff only and see where that gets me. I think it’s entirely safe; if I do a pull the worst that will happen is I’m on my own to do a manual merge. I may still keep using that git up Ruby command, too.
And now my rant. Fuck git. It’s insane to me that you have to do this kind of contortion. The default obvious tool should be the right one. I hate the neckbeardy attitude you read in most git discussions where the Superior Nerd gets to say “actually, it’s complicated because it needs to be blah blah”. That’s crap; it’s complicated because git has a bad UI and a bit too many exposed sharp corners for civilian use. (I particularly like the StackExchange guy’s observation “Note that the purpose of Git is to make it easy to share and consume the evolution of a codebase, not to precisely record history exactly as it unfolded.”) Git is amazing in many ways and has enabled a lot of things, but I sure wish a more humane alternative were the popular one.