Or, why I dislike squash merges. Tralfamadorians have the ability to experience reality in four dimensions; meaning, roughly, that they have total access to past, present, and future; they are able to perceive any point in time at will. Kurt Vonnegut The code usually tells you the what and sometimes the how. It doesn’t often delve into the why. That’s where the git commit messages come in. Squash merges tend to at worst eradicate them and at best jumble them into one single large commit message comprised of every squashed message.

I’ve seen some criticism of Git recently, on Twitter, with a ton of likes, suggesting a large amount of people have a difficult time using Git. Git is not that hard. It really isn’t. I think the problem stems from two main approaches. ### Problem the first: Shying away from the command line The command line reveals all but can be daunting for the beginner. I’d come from TortoiseSVN and then Kiln’s Mercurial equivalent before starting down the git-path.

I read the advice here some time ago, and I’ve been following it by and large. However, only recently I discovered how to enforce a line limit when git-commit starts up nano: ~/.gitconifg: [core] editor = nano -r 72 The problem is that doesn’t help limit the summary to 50 characters, which is what you need for log, shortlog, Github and general readability. I’ve now expanded this into a full replacement for git’s commit template.