Re: Git SVN Rebranching Issue

From: Eric Wong <normalperson@yhbt.net>
Date: Nov 6, 2008, 09:39 UTC
Message-ID: <20081106093917.GA15686@untitled>
In-Reply-To: <32541b130811041640x18e3bbfewa639df356ff7561e@mail.gmail.com>

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