On Saturday, 4 May 2013 23:28:21 UTC+1, Thomas Ferris Nicolaisen wrote: > On Friday, May 3, 2013 11:16:26 AM UTC+2, Geoff Ballinger wrote: > >> >> Is there anything I can do about this or do we have to accept this as >> part of the cost of moving to git? >> > > The short answer is yes. At least, that's what I experienced when doing > similar experiments with git-svn: You can't trace history across > repositories. This would probably require some smarter tool that would be > able to trace content by file-path, following SVN moves through history. >
Yes - have come to the same conclusion after much digging. The basic issue is that all of the import tools I have come across share the same implicit assumption that the SVN copy operation is just used for branching or forking - while in reality it is often used in a much more fine grain way to move/share files (along with their history) between projects. I guess this comes down to the fairly large philosophical differences between the two systems. > In some cases, it is possible to stitch history together from separate > git-svn clones using git grafts. Not sure if this will work in your case, > but here's a simple example: > http://blog.tfnico.com/2010/10/gitsvn-6-grafting-together-svn-history.html > For the larger macro-scale operations e.g. forks manually grafting history together makes sense - but for the file-by-file situation it isn't really practical. Would be hard pressed to track them all down for a start! To properly fix the problem it would require the import tool to fully explore the full SVN history for each individual file in the repo/root being converted to gather all the relevant commits and then synthesise an equivalent set of git commits, Geoff. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
