I don't commit changes in my working repos

May 29, 2015

I build a number of open source projects from source for various reasons of my own, using clones of the upstream master repos. With some of them, I make changes for my own reasons, often changes I will never be attempting to push upstream. Whenever I make changes this way, I do not commit my changes to the repos. This is the case whether the project uses Git or Mercurial.

The plain and simple truth is that if you're going to perpetually carry modest changes to an upstream project that changes frequently (and that you're going to re-pull frequently), not committing your changes is by far the easiest way to operate. If you have uncommitted changes, almost all of the time a simple 'git pull' or 'hg pull -u' will quietly get you up to date. If this doesn't work you can stash your changes in various ways, update to the latest version from a pristine setup, and then re-patch your changes. You spend a minimum amount of time interacting with the version control system, the actual checked in state of your repo exactly matches the master repo, and any time you want to know what you changed you can check 'git status' or 'hg diff' or so on. It's also really easy to temporarily or permanently set aside a particular change or set of them.

If you commit the changes, well, you have a bunch more work and your repo has now diverged from master. Every time you pull an upstream update, you must either merge or rebase your commits; even if the VCS will do this for you automatically this time, the merges or rebases are still there in repo history. If you do merges, any bisection is probably going to be more exciting. If you do rebases, your repo steadily accumulates a bunch of clutter in the corners. In either case monitoring the state of your changes is somewhat less straightforward, as is manipulating them.

It's my view that all of the stuff you have to do if you commit your changes is essentially make-work. There are cases where it's (potentially) useful, but those cases have been few and far between for me, and in the mean time I'd be doing a lot of VCS commands that I don't currently have to.

(I find the situation unfortunate but as far as I know neither Git nor Mercurial has extensions or features that would improve the situation. Git autorebase is sort of what I want, but not quite. Life is complicated by the fact that upstreams sometimes screw up their repos so that my local mirror repo diverges from their new reality, in which case I want to abandon my repo and just re-clone from upstream (and apply my changes again).)

(I mentioned this yesterday but I suspect it's a sufficiently odd way of working that I wanted to explain it directly.)


Comments on this page:

I commit local-only changes to git repos all the time, and `git pull --rebase` always works exactly like you're mentioning. It just pulls down the current branch & replays your local commit(s) on top of HEAD; there's no complicated merging or rebasing needed. (Unless, of course there's a conflict between the remote repo and your local change-- in which case you'd need to manually edit/merge stuff anyway.)

Yeah, I don’t get how keeping uncommitted local changes is supposed to be any easier than committing and rebasing.

A git pull --rebase will fetch the branch and then replay your local divergence on top of the new commits – no need to even stash anything. And you can configure git pull to default to rebasing rather than merging, so just a plain git pull is all you need to do.

That’s if there aren’t conflicts. If there are conflicts, then committing each of your changes individually as small patches usually limits the surface of each potential conflict, making their totality much easier to resolve than a giant hairy ball of unrelated conflicts all mixed together (and often causing each other).

I’m not speaking hypothetically here, I do exactly this stuff all day long. Maybe the remotes you pull from are somehow different? But the most likely sound of this to me is that you simply don’t understand your tool very well yet.

By cks at 2015-06-07 15:49:03:

My 'no commits' approach is ultimately historical; it's how I worked (and had to work) with upstream CVS and SVN repositories, so I carried it forward as the easy way to work with Mercurial and even Git repos when they started showing up. It sounds like I should reconsider this with at least Git, and try committing and rebasing my changes. There's even ways that this will probably make my life easier.

(Configuring git so that a plain 'git pull' does rebasing is definitely what I want, because otherwise I'll forget sometime and wind up in a mess.)

I have a lot of historical habits and things around here, and not all of them are wise by now.

Yeah, it’s not easy to approach a tool without preconceptions if you’ve already formed habits around a similar (at least vaguely) one. But my best guess from these entries is that you stand to gain a huge amount of convenience from an attempt at it. Git has easily been the most rewarding skill I have acquired – I would even rate it higher than (in my case) Vim.

Written on 29 May 2015.
« I don't find Github pull requests an easy way to submit patches
What I'm doing in reaction to Logjam (for HTTPS, SSH, and IKE) »

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

Last modified: Fri May 29 01:57:09 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.