Re: git-svn: follow parent after the fact?
- From
- Eric Wong <normalperson@yhbt.net>
- Date
- Dec 19, 2006, 07:47 UTC
- Message-ID
- <20061219074745.GA31338@localdomain>
- In-Reply-To
- <45873D0A.1040804@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
Show 5 quoted lines
> 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).
Show 7 quoted lines
> 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.