A month or so ago I wrote about how I don't commit changes in my working repos 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:
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 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.)