git pull: merge vs rebase

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.

6 thoughts on “git pull: merge vs rebase

  1. my thoughts as I read this: “…yeah…yeah…see, that’s why I use git pull –rebase too…fast forward is safer? hmm…I should do another deep dive and grok this…change my configs and retrain my muscle memory…but honestly I’d rather stick a rusty fork in my eye…next post, newsblur.”

    fuck git indeed. fuck it right in the ear. or maybe more appropriately, fuck our people for using it for everything just because it works for an extreme celebrity outlier like the Linux kernel. what a monstrous example of prioritizing abstraction, over-engineering, and edge cases over pragmatism and common sense.

  2. Yay, a fellow ranter! :-) I do wonder if any DCVS can be simpler to use. Everyone I know who’s used Mercurial says it’s easier to use than Git, but I don’t know if that’s just some cosmetics about the command line being better named or if some of the deeper data model stuff like merges, etc works better.

    Some of the visual git clients are quite nice. I wonder if they are trustworthy?

  3. If a rebase would lead to a merge conflict, then it pauses and actually gives pretty good instructions what to do: basically, it tells you to edit, add, commit (I think, but I don’t have to remember because the instructions tell me), and then git rebase –continue. Or git rebase –abort if that causes you to have second thoughts about the wisdom of the rebase, that will back out to before the rebase started.

  4. I’m trying to remember back to my Mercurial days – it was the first DVCS I used (partly because I had friends who used Mercurial and partly because Linus seem like an ass), and it was fine. But then I was pair programming with some friends who used git, and I liked some of the tools it had for helping me tell a better story with my commits, and with the extra staging and stashing, so I switched over to that. I don’t remember Mercurial being a lot nicer, but in retrospect I’m sure it helped me a ton that I learned git by pair programming; I certainly haven’t felt any desire to go back to Mercurial in the five or so years since I switched to Git.

    I don’t in general use visual Git clients. (Though I do use the github web interface for a few things, e.g. deleting obsolete branches on github.) And I have seen coworkers get a repo into a slightly unfortunate state by pressing buttons on visual Git clients. That was a few years ago, I hope they’ve gotten better since then.

    I recently ran across http://think-like-a-git.net which seems like it could contain some useful stuff? Not sure.

  5. Thing Like a Git is useful, thanks. The title reminds me of the book I really want, “The Little Git”, a book patterened off the old brilliant book of Lisp exercises called “The Little Lisper”.

Comments are closed.