Is Git grafting dangerous?

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

I suggest you ditch svn, since you're the only one using it and insist on using git, but supposing you can't do that for whatever reason, then I suggest you stop fighting your tools and just use git-svn in the usual sense.

Consider dropping your local history in favour of the "polished" history you're sending to svn. Your local history reflects your own work, which is work you're not yet prepared to show the world - certain test cases may be failing, or the code style may be ugly, etc. Make a local commit, polish it up, test it, and THEN put it into a nice little commit to be uploaded to the svn server.

You'll still have your local changes anyway using the reflog, for a time. If you really want to keep your own local hacks, then consider tagging them or something, so that they don't clutter your master branch.