== A lesson to myself: commit my local changes in little bits

For quixotic reasons, I recently updated my own local version of
[[dmenu ../sysadmin/ToolsDmenu]] to the upstream version, which had
moved on since I last did this (most importantly, it gained support
for [[Xft fonts ../unix/XFontTypes]]). Well, the upstream version
plus [[my collection of bugfixes and improvements GoingMyOwnWay]].
In the process of doing this I have (re)learned a valuable lesson
about how I want to organize my local changes to upstream software.

My modifications to dmenu predate [[my recent decision to commit
local changes instead of just carrying them uncommitted on top of
the repo GitCommitAndRebaseNotes]]. So the first thing I did was
to just commit them all in a single all in one changeset, then fetch
upstream and rebase. This had rebase conflicts, of course, so I
merged them and built the result. This didn't entirely work; some
of my modifications clearly hadn't taken. Rather than try to patch
the current state of my modifications, I decided to punt and do it
the right way; starting with a clean copy of the current upstream,
I carefully separated out each of my modifications and added them
as separate changes and commits. This worked and wasn't particularly
much effort (although there was a certain amount of tedium).

Now, a certain amount of the improvement here is simply that I was
porting all of my changes into the current codebase instead of trying
to do a rebase merge. This is always going to give you a better chance
to evaluate and test things. But that actually kind of points to a
problem; because I had my changes in a single giant commit, everything
was tangled together and I couldn't see quite clearly enough to do the
rebase merge right. Making each change independently made things much
clearer and easier to follow, and I suspect that that would have been
true even in a merge.  The result is also easier for me to read in the
future, since each change is now something I can inspect separately.

All of this is obvious to people who've been dealing with VCSes and
local modifications, of course. And in theory I knew it too, because
I've read all of those homilies to good organization of your changes.
I just hadn't stubbed my toe on doing it the 'wrong' way until now
(partly because I hadn't been committing changes at all until
recently).

(Of course, this is another excellent reason to commit local changes
instead of carrying them uncommitted. Uncommitted local changes are
basically intrinsically all mingled together.)

Having come to my senses here, I have a few more programs with
local hacks that I need to do some change surgery on.

(I've put my version of dmenu [[up on github
https://github.com/siebenmann/dmenu-cks]], where you can see and
cherry pick separate changes if desired. I expect to rebase this
periodically, when [[upstream http://tools.suckless.org/dmenu/]]
updates and I notice and care. As before, I have no plans to try
to push even my bugfixes to the official release, but interested
parties are welcome to try to push them upstream.)

=== Sidebar: '_git add -p_' and this situation

In theory I could have initially committed my big ball of local
changes as separate commits with '_git add -p_'. In practice this
would have required disentangling all of the changes from each
other, which would have required understanding code I hadn't touched
for [[two years or so GoingMyOwnWay]]. I was too impatient at the
start to do that; I hoped that 'commit and rebase' would be good
enough. When it wasn't, restarting from scratch was easier because
it let me test each modification separately as I made it.

Based on this, my personal view is that I'm only going to use '_git
add -p_' when I've recently worked on the code and I'm confident
that I can accurately split changes up without needing to test the
split commits to make sure each is correct on its own.