Is Git grafting dangerous?
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:
- Make topic branch for Trac ticket
- Hack away, making several commits
git rebase -ion a disconnected HEAD to bundle all the work into a single commit (keeping the topic branch intact)
git svn dcommitto commit to SVN
- Merge the feature back to
master, then merge from
master(this second step is generally a no-op, since trunk and the feature branch should match)
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
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
dcommit dance, am I asking for trouble? Should I just get over myself? 🙂
2 Solutions collect form web for “Is Git grafting dangerous?”
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.
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.