Question

I’ve been using Git as a fat client for a Subversion repo, which has been great. I’m supposed to follow the one-commit-per-Trac-ticket methodology, but I much prefer having a rich history of atomic commits for my own benefit, so I’ve gotten into the following habit:

1. Make topic branch for Trac ticket
2. Hack away, making several commits
3. Use git rebase -i on a disconnected HEAD to bundle all the work into a single commit (keeping the topic branch intact)
4. Use git svn dcommit to commit to SVN
5. Merge the feature back to master, then merge from trunk to master (this second step is generally a no-op, since trunk and the feature branch should match)

This keeps master and trunk nicely in sync while keeping all the history I want. Only trouble is that Git thinks that master is forever well ahead of trunk, since as far as it knows I’ve never once actually committed either a topic branch or master back to trunk — step #3 loses the ancestry of the changes, so all Git sees is trunk humming along by itself and master merging both from it and the topic branches:

Switched to branch 'master'
Your branch and 'trunk' have diverged,
and have 232 and 1 different commit(s) each, respectively.

Now, I don’t actually know that this is a problem. I’m mostly the only one working in this SVN repo, so it’s not like there are tricky merges to deal with that could get confused. But it bothers me, just on principle (I’m like that). I’d like the trunk commits to reflect their “true” ancestry — each one is a merge with the previous SVN revision as one parent and the topic branch as the other.

And lo and behold, there’s .git/info/grafts, which appears to do precisely what I want. I can even merge trunk to master as a fast-forward merge, which morally it usually absolutely is. But pretty though the results may be, it seems kludgy, especially since it may not be absolutely necessary.

So what I want to know is, is there anything dangerous about this idea? If I, say, get into the habit of making a graft each time I do the rebase/dcommit dance, am I asking for trouble? Should I just get over myself? 🙂

Answer 1

Old question, I know, but:

I think maintaining a difference between “trunk” and “master” is making your life harder than necessary. “master” should generally point to the top of the svn tree, or to quick fixes you’re about to dcommit. When you’ve bundled up a series of changes and dcommitted, them, though, I think the next logical step is to set up a graft so that the change you dcommitted is a child of both its svn parent and the topic branch you used to write the code for the ticket. In other words, the change you dcommitted becomes, from git’s perspective, a merge of the svn tree and your topic branch — which, it many respects, is what it is. There’s no need to create a bona fide git merge of the topic branch at all.