2015-07-07
The Git 'commit local changes and rebase' experience is a winning one
I mentioned recently that I'd been persuaded to change my ways from leaving local changes uncommitted in my working repos to committing them and rebasing on pulls. When I started this, I didn't expect it to be any real change from the experience of pulling with uncommitted changes and maybe stashing them every so often and so on; I'd just be doing things the proper and 'right' Git way (as everyone told me) instead of the sloppy way.
I was wrong. Oh, certainly the usual experience is the same; I do a
'git pull', I get my normal pull messages and stats output, and
Git adds a couple of lines at the end about automatically rebasing
things. But with local commits and rebasing, dealing with conflicts
after a pull is much better. This isn't because I have fewer or
simpler changes to merge, it's simply because the actual user interface
and process is significantly nicer. There's very little fuss and muss;
I fire up my editor on a file or two, I look for the '<<<<' markers, I
sort things out, I can get relatively readable diffs, and then I can
move on smoothly.
(And the messages from git during rebasing are actually quite helpful.)
Re-applying git stashes that had conflicts with the newly pulled
code was not as easy or as smooth, at least for the cases that I
dealt with. My memory is that it was harder to see my changes and
harder to integrate them, and also sometimes I had to un-add things
from the index that git stash had apparently automatically added
for me. I felt far less in control of the whole process than I do
now with rebasing.
(And with rebasing, the git reflog means that if I need to I can revert my repo to the pre-pull state and see exactly how things were organized in the old code and what the code did with my changes integrated. Sometimes this is vital if there's been a significant restructuring of upstream code. In the past with git stash, I've been lucky because I had an intact pre-pull copy of the repo (with my changes) on a second machine.)
I went into this expecting to be neutral on the change to 'commit and rebase on pulls'. I've now wound up quite positive on it; I actively like and prefer to be fixing up a rebase to fixing up a git stash. Rebasing really is better, even if I just have a single small and isolated change.
(And thank you to the people who patiently pushed me towards this.)