I have a git-svn issue which keeps biting me. My company uses svn as its primary version control system. We frequently create branches, e.g. /branches/somebranch, by forking the trunk to ensure stability over the "somebranch" code. The problem is that we also frequently blow away /branches/somebranch and refork it from the trunk. git-svn does a good job for most work, but I notice that if you delete the "somebranch" branch in svn and then refork it, also in svn, then when you git-svn fetch, the git commit at the head of remotes/somebranch will have two parents: the first is the previous head of remotes/somebranch, and the second is the head of remotes/trunk. Surely only the remotes/trunk parent should be listed? Any connection with the previous remotes/somebranch is an accident of naming. The real problem then comes when you come to look at the history in gitk. If "somebranch" is rebranched many times, the git history starts looking pretty complicated, when in fact it should simply be the linear history of remotes/trunk up to the branch point followed by a few, branch-specific commits. Is there any way to prevent (or modify) the git history to remove the errant parent? In the ideal world, we wouldn't reuse branch names in svn, but it is convenient and doesn't cause problems for svn users. I can't force the rest of the company to change to accommodate my use of git... I am using git (svn) version 1.5.6.5 (svn 1.4.6) from Debian/Lenny and can provide a trivial repository demonstrating the problem if anyone is interested. Matt -- Matt Kern http://www.undue.org/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
