Git's selective commits plus Magit are a killer feature for me

September 23, 2016

I'm sure there are some people who are meticulously organized in their programming work. They work on only one thing at a time, or if they're making multiple changes they carefully separate them on different topic branches. I'm not one of them. I'm working away on something, but then I can't resist improving something that I stumble over because I was in that area of the code, and I run into a bug that needs to be corrected, and by the time I turn around there's a bunch of unrelated changes all piled in together.

I think git has had 'git add -p' for as long as I've been using it, but in practice it was never usable enough for me. I couldn't stand the tedious grind needed and I made mistakes and sometimes the changes I wanted to separated were in what git considered one chunk. I made a couple of dutiful attempts to use it and make those proper neat commits but soon gave it up as too much of a pain. If I was lucky my unrelated changes were in separate files and I'd make multiple commits; otherwise, well, there were big commits with big change lists and sometimes casual admissions in asides that I'd also done some additional work.

When I first started with Magit I didn't really expect anything much to change with me and git. Sure, I was picking Magit up to make selective commits easier and it did that, but I didn't think that was all that big. After all, most of my separate changes were already to separate files; I at least remembered the really entangled changes as rare.

I was wrong. Easy selective commits have turned into a killer feature of the git plus Magit combination, and I've wound up making them all the time. I think part of it is that having them available is by itself liberating, and encourages me to make most changes freely. I know that I can sort everything out later, that I can let changes mature and evolve at different rates, and so on. So any time I see something I want to tweak or fix or correct, I can do it right then and there. So I do.

(This is especially useful for small single-file programs, such as this one I've been working on recently. Almost all of the commits to it are entangled ones that I sorted out with Magit.)

Sidebar: Magit's taking over making almost all of my commits

Why is pretty straightforward; it's a nicer environment than moving between multiple xterm windows to check diffs, stage changes, make a commit, call up an editor and a spell checker, and so on. Magit has conveniences like warning me if the first line of the commit is getting too long and it inherits all of the straightforward GNU Emacs features like on the fly spellchecking with flyspell mode (once I looked up and worked out how to add it to my Emacs setup in a way that worked). So I wind up writing better commit messages (or at least better spelled ones) with generally less work.

As someone who thinks of himself as a Unix person, I'm not entirely copacetic about GNU Emacs swallowing more of my command line work. But these days I'm a pragmatist too, and Magit and GNU Emacs sure are convenient here. I've even wound up using Magit for some commit amending just because it was easy enough (and easier to look up in the Magit manual than wrestle with figuring out the exact command line incantation I was going to need).

Written on 23 September 2016.
« Why we've wound up without ZFS ZILs or L2ARCs on our pools
You probably want to start using the -w option with iptables »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 23 01:24:33 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.