Question

This is what I’d like my workflow to look like at a conceptual level:

1. I hack on my new feature for a while
2. I notice a typo in a comment
   • I change it
   • Since the typo is completely unrelated to anything else, I put that change in a pile of comment fixes
3. I keep working on the code
4. I realize I need to flesh out a few utility functions
   • I do so
   • I put that change in its own pile
5. Steps 2, 3, and 4 each repeat throughout the day
6. I finish the new feature and put the changes for that feature in a pile
7. I push nice patches upstream: One with the new feature, a few for the other tweaks, and one with a bunch of comment fixes if enough have accumulated

Since I’m both lazy and a perfectionist, I want to be able to do some things out of order: I might correct a typo but forget to put it in the comment fix pile; when I prepare the upstream patches (I’m using git-svn, so I need to be pretty deliberate about these), I’ll then pull out the comment fixes at that point. I might forget to separate things altogether until the very end. But I might /also/ have committed some of the piles along the way (sorry, the metaphor is breaking down …).

This is all rather like just using Eclipse changesets with SVN, only I can have different changes to the same file in different piles (having to disentangle changes into different commits is what motivated me to move to git-svn, in fact …), and with Git I can have my full discombobulated change history, experimental branches and all, but still make a nice, neat patch.

I’ve just recently started with Git after having wanted to for a good while, and I’m quite happy so far. The biggest way in which the above workflow doesn’t really map into Git, though, is that a “bin” can’t really be just a local branch, since the working tree only ever reflects the state of a single branch. Or maybe the Git index is a “pile,” and what I want is to have more than one somehow (effectively).

I can think of a few ways to approximate what I want (maybe creative use of stash? Intricate stash-checkout-merge dances?), but my grasp on Git isn’t solid enough to be sure of how best to put all the pieces together. It’s said that Git is more a toolkit than a VCS, so I guess the question comes down to: How do I build this thing with these tools?

Answer 1

It sounds like what you want to do is to create lots of commits each time you do something separate, and then use git rebase -i to reorder and combine your commits before pushing them upstream.

The rebase function is one of the really powerful features of Git, and it seems well suited to your mode of operation.

Since you can change commit messages with rebase, you could add a “tag” like “COMMENT” or “UTILS” to each related commit, so you can easily identify them later when you shuffle things around with git rebase -i.

One of the limitations of git svn dcommit may be awkward – you can only send up a “complete” set (from a Git point of view) of patches to Subversion. That is, dcommit only commits from the point you started making changes, to the HEAD. If you have commits (like your typos) that you want to keep around for some later batch commit, then you can make a temporary branch for those, using git rebase to keep it up to date.

I have on my “list of things to do sometime” to try to make a patch for git svn dcommit that lets you choose which patches to send up to Subversion.