The Git 'commit local changes and rebase' experience is a winning one

July 7, 2015

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.)

Written on 07 July 2015.
« My Django form field validation and cleanup pain
Making GTK applications in alternate locations, settings edition »

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

Last modified: Tue Jul 7 02:07:44 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.