On Thu, Nov 6, 2008 at 4:39 AM, Eric Wong <normalperson@xxxxxxxx> wrote: > Avery Pennarun <apenwarr@xxxxxxxxx> 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 -- 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
