Steven Grimm <koreth@xxxxxxxxxxxxx> wrote: > One of the other git users here just noticed that his git-svn clone of a > particular svn repo has an inconsistent set of files compared to the svn > client. Turns out the repo has had its trunk moved around in the past. A > fresh clone with --follow-parent (which he didn't use) produces the > correct results. The final set of files at the latest (svn) revision was inconsistent? That should never happen... If so, I'd very much like to look into this. > Obviously he can blow away his current repo and make a new one, but it'd > be nicer if he could preserve his local change history. Is there any way > to retroactively apply the additional changes --follow-parent would have > applied if it had been used on the initial fetch? git-svn graft-branches can probably work (if he imported the parent separately). > It would be better, IMO, if you didn't have to figure out whether or not > a given remote svn repository has had branch renames in the past in > order to figure out if you need to provide an extra option to git-svn > fetch. Maybe --follow-parent should be the default behavior and there > should be an option to turn it off? Or is there a good reason to not > want that behavior most of the time? My assumption is that it's not the > default simply because it's a recent addition. It may behave unpredictably on some poorly organized repositories. I haven't quite debugged this problem fully as the current code to handle multiple repositories is a hacked-on mess. I'm currently refactoring git-svn to work better on multi-remote operations and --follow-parent should be easier to debug as a result. > By the way, I'm completely in favor of renaming commit to set-tree. +1 > for that change. Noted, thanks for the input. -- 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