Git SVN Rebranching Issue

Git SVN Rebranching Issue

[Matt Kern]

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/

Re: Git SVN Rebranching Issue

[Eric Wong]

Matt Kern <matt.kern@undue.org> 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

Re: Git SVN Rebranching Issue

[Dmitry Potapov]

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

Re: Git SVN Rebranching Issue

[Sverre Rabbelier]

On Tue, Nov 4, 2008 at 10:42, 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 think what was meants is to use grafts and then make them permanent
with 'git filter-branch'.

-- 
Cheers,

Sverre Rabbelier

Re: Git SVN Rebranching Issue

[Matt Kern]

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

Re: Git SVN Rebranching Issue

[Eric Wong]

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

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

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

Re: Git SVN Rebranching Issue

[Avery Pennarun]

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.

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

Re: Git SVN Rebranching Issue

[Eric Wong]

Avery Pennarun <apenwarr@gmail.com> wrote:
> 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.

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

> 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

Re: Git SVN Rebranching Issue

[Avery Pennarun]

On Thu, Nov 6, 2008 at 4:39 AM, Eric Wong <normalperson@yhbt.net> wrote:
> 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.

> 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