== Some notes on my 'commit local changes and rebase' Git workflow

A month or so ago I wrote about [[how I don't commit changes in my
working repos NotCommittingChanges]] and in reaction to it several
people argued that I ought to change my way. Well, never let it be
said that I can't eventually be persuaded to change my ways, so
since then I've been cautiously moving to committing my changes and
rebasing on pulls in a couple of Git repos. I think I like it, so
I'm probably going to make it my standard way of working with Git
in the future.

The Git configuration settings I'm using are:

.pn prewrap on
>  git config pull.rebase true
>  git config rebase.stat true

The first just makes '_git pull_' be '_git pull --rebase_'. If I
wind up working with multiple branches in repos, I may need to set
this on a per-branch basis or something; so far I just track
_origin/master_ so it works for me. The second preserves the normal
'_git pull_' behavior of showing a summary of updates, which I find
useful for keeping an eye on things.

One drawback of doing things this way is that '_git pull_' will now
abort if there are also uncommitted changes in the repo, such as I
might have for a very temporary hack or test. I need to remember
to either commit such changes or do '_git stash_' before I pull.

(The other lesson here is that I need to learn how to manipulate
rebase commits so I can alter, amend, or drop some of them.)

Since I've already done this once: if I have committed changes in
a repo without this set, and use '_git pull_' instead of '_git pull
--rebase_', one way to abort the resulting unwanted merge is '_git
reset --hard HEAD_'. Some sources suggest '_git reset --merge_' or
'_git merge --abort_' instead. But really I should set pull rebasing
to on the moment I commit my own changes to a repo.

(There are a few repos around here that now need this change.)

I haven't had to do [[a bisection ../linux/GitBisectNotes]] on a
commit-and-rebase repo yet, but I suspect that bisection won't go
well if I actually need my changes in all versions of the repo that
I build and test.  If I wind up in this situation I will probably
temporarily switch to uncommitted changes and use of '_git stash_',
probably in a scratch clone of the upstream master repo.

(In general I like cloning repos to keep various bits of fiddling
around in them completely separate. Sure, I probably could mix
various activities in one repo without having things get messed up,
but a different directory hierarchy that I delete afterwards is the
ultimate isolation and it's generally cheap.)