Re: Git SVN Rebranching Issue

[Eric Wong <normalperson@yhbt.net>]

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