Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@xxxxxxxx> wrote: > > Dmitry Potapov <dpotapov@xxxxxxxxx> 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 -- 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
