git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git-svn: follow parent after the fact?

From
Steven Grimm <koreth@midwinter.com>
Date
Dec 19, 2006, 01:14 UTC
Message-ID
<45873D0A.1040804@midwinter.com>

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.

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?

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.

By the way, I'm completely in favor of renaming commit to set-tree. +1 for that change.

Next: Eric Wong
Message 1 of 3 in “git-svn: follow parent after the fact?”
  1. Steven GrimmDec 19, 2006
  2. Eric WongDec 19, 2006
  3. Steven GrimmDec 19, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.