Matt Kern <matt.kern@xxxxxxxxx> wrote: > 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? Hi Matt, Short answer: you can use grafts to remove parents. It was actually an intentional design decision on my part preserve parents based on branch name. We would eventually otherwise lose history of the now-deleted branches, as reflogs can expire. To me, it's easier to drop history connections you don't want with grafts than to recover it by refetching. -- Eric Wong -- 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
