{"thread":{"id":"43304","subject":"git-svn: follow parent after the fact?","startedAt":"2006-12-19T01:14:50Z","lastAt":"2006-12-19T21:36:59Z","messageCount":3,"participants":["Steven Grimm","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294285","messageId":"45873D0A.1040804@midwinter.com","threadId":"43304","inReplyTo":null,"subject":"git-svn: follow parent after the fact?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-19T01:14:50Z","receivedAt":"2006-12-19T01:14:50Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"One of the other git users here just noticed that his git-svn clone of a \nparticular svn repo has an inconsistent set of files compared to the svn \nclient. Turns out the repo has had its trunk moved around in the past. A \nfresh clone with --follow-parent (which he didn't use) produces the \ncorrect results.\n\nObviously he can blow away his current repo and make a new one, but it'd \nbe nicer if he could preserve his local change history. Is there any way \nto retroactively apply the additional changes --follow-parent would have \napplied if it had been used on the initial fetch?\n\nIt would be better, IMO, if you didn't have to figure out whether or not \na given remote svn repository has had branch renames in the past in \norder to figure out if you need to provide an extra option to git-svn \nfetch. Maybe --follow-parent should be the default behavior and there \nshould be an option to turn it off? Or is there a good reason to not \nwant that behavior most of the time? My assumption is that it's not the \ndefault simply because it's a recent addition.\n\nBy the way, I'm completely in favor of renaming commit to set-tree. +1 \nfor that change.\n\n"},{"id":"297456","messageId":"20061219074745.GA31338@localdomain","threadId":"43304","inReplyTo":"45873D0A.1040804@midwinter.com","subject":"Re: git-svn: follow parent after the fact?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-12-19T07:47:45Z","receivedAt":"2006-12-19T07:47:45Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Steven Grimm <koreth@midwinter.com> wrote:\n> One of the other git users here just noticed that his git-svn clone of a \n> particular svn repo has an inconsistent set of files compared to the svn \n> client. Turns out the repo has had its trunk moved around in the past. A \n> fresh clone with --follow-parent (which he didn't use) produces the \n> correct results.\n\nThe final set of files at the latest (svn) revision was inconsistent?\nThat should never happen...  If so, I'd very much like to look into this.\n\n> Obviously he can blow away his current repo and make a new one, but it'd \n> be nicer if he could preserve his local change history. Is there any way \n> to retroactively apply the additional changes --follow-parent would have \n> applied if it had been used on the initial fetch?\n\ngit-svn graft-branches can probably work (if he imported the parent\nseparately).\n\n> It would be better, IMO, if you didn't have to figure out whether or not \n> a given remote svn repository has had branch renames in the past in \n> order to figure out if you need to provide an extra option to git-svn \n> fetch. Maybe --follow-parent should be the default behavior and there \n> should be an option to turn it off? Or is there a good reason to not \n> want that behavior most of the time? My assumption is that it's not the \n> default simply because it's a recent addition.\n\nIt may behave unpredictably on some poorly organized repositories.  I\nhaven't quite debugged this problem fully as the current code to handle\nmultiple repositories is a hacked-on mess.\n\nI'm currently refactoring git-svn to work better on multi-remote\noperations and --follow-parent should be easier to debug as a result.\n\n> By the way, I'm completely in favor of renaming commit to set-tree. +1 \n> for that change.\n\nNoted, thanks for the input.\n\n-- \n"},{"id":"297054","messageId":"45885B7B.6060308@midwinter.com","threadId":"43304","inReplyTo":"20061219074745.GA31338@localdomain","subject":"Re: git-svn: follow parent after the fact?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-19T21:36:59Z","receivedAt":"2006-12-19T21:36:59Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Eric Wong wrote:\n> The final set of files at the latest (svn) revision was inconsistent?\n> That should never happen...  If so, I'd very much like to look into this.\n>   \n\nYes, that's right; there are about 50 files that were in the original \ntrunk before it was renamed but weren't in the branch that became the \nnew trunk. Those files are present in the git repo if I use plain \ngit-svn fetch, but they're not there in an svn client or in a git repo \nwhere I've used --follow-parent.\n\nSo far I haven't been able to come up with a from-scratch test case to \ndemonstrate this behavior. The svn repository in question, \nunfortunately, isn't a public one. I've asked the person in charge of \nthe repo if he remembers what exactly he did at the time of the branch \nreorganization; so far every permutation I've tried in my test repo has \nworked fine and not had the problem, so something odd must have happened \nin that repo's history.\n\nI'll follow up if/when I manage to get a good test case.\n\n"}]}