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

July 3, 2015

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

Comments on this page:

I need to remember to either commit such changes or do 'git stash' before I pull.

Note the --autostash switch to git rebase, which can be enabled by default with the rebase.autostash config setting.

In general I like cloning repos to keep various bits of fiddling around in them completely separate.

Revisiting this entry after your more recent one, another note: in Git 2.5 it may be worthwhile to you to create new worktrees instead of full clones.

By cks at 2015-09-04 22:23:36:

My off the cuff view is that if I'm sufficiently nervous to clone a separate repo, I want to keep not just the working tree but also the .git side of things completely separate just in case. I'm probably being more nervous than I need to be, but (temporary) disk space is cheap for most repos I work with. A full clone means that I can be absolutely sure that nothing I do in the new repo will contaminate my main one (unless and until I pull/push over).

It wasn’t disk space savings that compelled my suggestion, it was the ease of sharing the results with the original repository, without fiddling with remotes. That reduces friction vs using full clones as there’s less pushing commits around explicitly, which I thought it might be helpful. Of course if your goal is complete isolation, then that’s exactly what you don’t want, so yeah.

Written on 03 July 2015.
« Some thoughts on Go compiler directives being in source comments
Wandering Thoughts is now ten years old »

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

Last modified: Fri Jul 3 01:21:50 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.