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:

  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:

  • How can I include the development branch of Ansible with my playbooks when checked out via Git?
  • How can i copy a file from local commit on a different branch?
  • Force remove all commits ahead of HEAD?
  • git problem with getting previous file version
  • Unable to git fetch - Connection reset by peer
  • Forking on Google Code (or any other SVN hosting)
  • 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? 🙂

  • GIT refs/heads/master does not point to a valid object
  • Converting Git workflow to Mercurial
  • What are these options in qgit?
  • git conflict with differently cased directory name
  • In which branch should a beta release be tagged?
  • Permission Denied Github (push)
  • 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.

    Git Baby is a git and github fan, let's start git clone.