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

[[I mentioned recently GitCommitAndRebaseNotes]] that I'd been
persuaded to change my ways from [[leaving local changes uncommitted
in my working repos NotCommittingChanges]] 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 https://git-scm.com/docs/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.)