threads / discuss / 16152

Git SVN Rebranching Issue

Subject: Git SVN Rebranching Issue

## tl;dr

9 messages between Nov 3, 2008 and Nov 6, 2008.

replies: 8people: 5as markdown or json

Matt Kern· Nov 3, 2008, 14:07 UTC · lore

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/

Eric Wong· Nov 4, 2008, 08:41 UTC · re: Matt Kern · lore

Re: Git SVN Rebranching Issue

Matt Kern <matt.kern@undue.org> wrote:

Show 21 quoted lines

> 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

Dmitry Potapov· Nov 4, 2008, 09:42 UTC · re: Eric Wong · lore

Re: Git SVN Rebranching Issue

On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:

> 
> Short answer: you can use grafts to remove parents.

Using grafts requires some cautious, especially when it is used to make some commits unreachable, because git gc can remove unreachable commits. Also, a repository with grafts cannot be cloned. So using grafts looks like more as workaround rather a real solution.

> 
> 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.

Would it not be better to save the old branch using "@SVN-NUMBER" as suffix? Thus, those do not need the old branch can easily delete it.

Dmitry

Sverre Rabbelier· Nov 4, 2008, 10:15 UTC · re: Dmitry Potapov · lore

Re: Git SVN Rebranching Issue

On Tue, Nov 4, 2008 at 10:42, Dmitry Potapov <dpotapov@gmail.com> wrote:

Show 7 quoted lines

> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> Short answer: you can use grafts to remove parents.
>
> Using grafts requires some cautious, especially when it is used to make
> some commits unreachable, because git gc can remove unreachable commits.
> Also, a repository with grafts cannot be cloned.  So using grafts looks
> like more as workaround rather a real solution

I think what was meants is to use grafts and then make them permanent with 'git filter-branch'.

-- 
Cheers,

Sverre Rabbelier

Matt Kern· Nov 4, 2008, 11:24 UTC · re: Dmitry Potapov · lore

Re: Git SVN Rebranching Issue

Show 6 quoted lines

> > 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.
> 
> Would it not be better to save the old branch using "@SVN-NUMBER" as
> suffix? Thus, those do not need the old branch can easily delete it.

I would second this approach.

Our svn repository isn't particularly big or old, but if someone were to make a branch now, there is a fair chance it will have the same name as an old branch but have absolutely nothing to do with that old branch. The situation will only get worse as our svn repository grows and more branches are created/deleted.

Matt

-- 
Matt Kern
http://www.undue.org/

Eric Wong· Nov 5, 2008, 00:33 UTC · re: Dmitry Potapov · lore

Re: Git SVN Rebranching Issue

Dmitry Potapov <dpotapov@gmail.com> wrote:

Show 8 quoted lines

> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
> > 
> > Short answer: you can use grafts to remove parents.
> 
> Using grafts requires some cautious, especially when it is used to make
> some commits unreachable, because git gc can remove unreachable commits.
> Also, a repository with grafts cannot be cloned.  So using grafts looks
> like more as workaround rather a real solution.

I don't think extra history is harmful at all, so the grafts could even be temporary. AFAIK, the extra history is only an aesthetic issue in visualizers (and I actually like to see it myself).

Besides, git svn is just a workaround until the SVN repository is replaced entirely by git :)

Show 6 quoted lines

> > 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.
> 
> Would it not be better to save the old branch using "@SVN-NUMBER" as
> suffix? Thus, those do not need the old branch can easily delete it.

That would require renaming _existing_ branches to their "@SVN-NUMBER" name; which would break mechanisms for tracking branches based on refname.

-- 
Eric Wong

Avery Pennarun· Nov 5, 2008, 00:40 UTC · re: Eric Wong · lore

Re: Git SVN Rebranching Issue

On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:

Show 13 quoted lines

> Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> >
>> > Short answer: you can use grafts to remove parents.
>>
>> Using grafts requires some cautious, especially when it is used to make
>> some commits unreachable, because git gc can remove unreachable commits.
>> Also, a repository with grafts cannot be cloned.  So using grafts looks
>> like more as workaround rather a real solution.
>
> I don't think extra history is harmful at all, so the grafts could even
> be temporary.  AFAIK, the extra history is only an aesthetic issue in
> visualizers (and I actually like to see it myself).

But it's *lying* history in this case; it doesn't reflect what really happened in svn *or* in real life. I'd say lying history is most often harmful. "git blame" and "git log" will lie in this case, for example.

Show 6 quoted lines

>> Would it not be better to save the old branch using "@SVN-NUMBER" as
>> suffix? Thus, those do not need the old branch can easily delete it.
>
> That would require renaming _existing_ branches to their "@SVN-NUMBER"
> name; which would break mechanisms for tracking branches based on
> refname.

Well, you wouldn't have to rename the existing branch. You would simply create the new @SVN-NUMBER branch when it became clear that that commit is no longer reachable from the undecorated branch ref. Isn't that why the @SVN-NUMBER branches are needed in the first place?

As for tracking branches based on refname, it seems like the current behaviour of pretending to merge histories together wouldn't work too well anyway. For someone pulling from the messed-up branch, they really *will* need to rewind and re-pull, since that's exactly what happened in svn. I don't think git has any chance of doing this automatically just because of a new commit with two parents.

Disclaimer: I haven't run into any of this myself since I don't
recycle branch names in svn :)

Have fun,

Avery

Eric Wong· Nov 6, 2008, 09:39 UTC · re: Avery Pennarun · lore

Re: Git SVN Rebranching Issue

Avery Pennarun <apenwarr@gmail.com> wrote:

Show 19 quoted lines

> On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Dmitry Potapov <dpotapov@gmail.com> wrote:
> >> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
> >> >
> >> > Short answer: you can use grafts to remove parents.
> >>
> >> Using grafts requires some cautious, especially when it is used to make
> >> some commits unreachable, because git gc can remove unreachable commits.
> >> Also, a repository with grafts cannot be cloned.  So using grafts looks
> >> like more as workaround rather a real solution.
> >
> > I don't think extra history is harmful at all, so the grafts could even
> > be temporary.  AFAIK, the extra history is only an aesthetic issue in
> > visualizers (and I actually like to see it myself).
> 
> But it's *lying* history in this case; it doesn't reflect what really
> happened in svn *or* in real life.  I'd say lying history is most
> often harmful.  "git blame" and "git log" will lie in this case, for
> example.

Maybe, but I don't find having a choice to follow _either_:
  a) copy history (the REAL history)
  b) the name history (faked)

I've had to deal with repositories that recycled branch names for a while now and it hasn't been an issue for me nor anybody else using git svn on them.

git log --first-parent exists for following copy history, too.

Show 11 quoted lines

> >> Would it not be better to save the old branch using "@SVN-NUMBER" as
> >> suffix? Thus, those do not need the old branch can easily delete it.
> >
> > That would require renaming _existing_ branches to their "@SVN-NUMBER"
> > name; which would break mechanisms for tracking branches based on
> > refname.
> 
> Well, you wouldn't have to rename the existing branch.  You would
> simply create the new @SVN-NUMBER branch when it became clear that
> that commit is no longer reachable from the undecorated branch ref.
> Isn't that why the @SVN-NUMBER branches are needed in the first place?

Making @SVN-NUMBER branches for new/latest branches is even more confusing. That would mean the user would have to remember the @SVN-NUMBER every time they wanted to do operations with the recycled branch.

The current use of @SVN-NUMBER in branches are only used when following parents (when repositories are rearranged). In retrospect, it's probably possible to for git-svn to not make them user-visible (I seem to recall they made development/debugging/testing easier in the past, though).

Show 6 quoted lines

> As for tracking branches based on refname, it seems like the current
> behaviour of pretending to merge histories together wouldn't work too
> well anyway.  For someone pulling from the messed-up branch, they
> really *will* need to rewind and re-pull, since that's exactly what
> happened in svn.  I don't think git has any chance of doing this
> automatically just because of a new commit with two parents.

"git svn rebase" and "git log ..$RECYCLED" both work. non-FF/non-squash pulls won't, of course.

> Disclaimer: I haven't run into any of this myself since I don't
> recycle branch names in svn :)

Lucky you :)

-- 
Eric Wong

Avery Pennarun· Nov 6, 2008, 20:48 UTC · re: Eric Wong · lore

Re: Git SVN Rebranching Issue

On Thu, Nov 6, 2008 at 4:39 AM, Eric Wong <normalperson@yhbt.net> wrote:

Show 10 quoted lines

> Avery Pennarun <apenwarr@gmail.com> wrote:
>> Well, you wouldn't have to rename the existing branch.  You would
>> simply create the new @SVN-NUMBER branch when it became clear that
>> that commit is no longer reachable from the undecorated branch ref.
>> Isn't that why the @SVN-NUMBER branches are needed in the first place?
>
> Making @SVN-NUMBER branches for new/latest branches is even more
> confusing.  That would mean the user would have to remember the
> @SVN-NUMBER every time they wanted to do operations with the
> recycled branch.

Hmm, I wasn't suggesting using @SVN-NUMBER for the *latest* branches; you create one for the older branches at the time the old one is replaced by the new one.

Note that this is exactly how it works in svn, so in fact it's a very clean mapping from svn onto git. If I ask about /branches/whatever/myfile.c@SVN-NUMBER, it's different from asking about "-r SVN-NUMBER /branches/whatever/myfile.c". The difference is precisely what we're talking about representing here.

What's important is that they really are two totally unrelated branches of history, which happen to have been referred to by the same name at the time when they were current.

Show 5 quoted lines

> The current use of @SVN-NUMBER in branches are only used when following
> parents (when repositories are rearranged).  In retrospect, it's
> probably possible to for git-svn to not make them user-visible (I seem
> to recall they made development/debugging/testing easier in the past,
> though).

I wouldn't want to lose those names as they are now; they're inconvenient, but important, because they accurately represent the important points in svn history as it has been imported.

Have fun,

Avery