Robert Zeh <robert.a.zeh@xxxxxxxxx> wrote: > So is the basic problem that the history of the branch is unknown and we > have to retrieve the history? Yes, or rather it's not known that it's a branch/tag: Say you have something like this: /trunk/client /trunk/server /trunk/design_docs_specs_and_whatnot /tags/client_1.0 /tags/client_1.1 /tags/server_1.0 /tags/server_1.1 But you're tracking /trunk, /tags/*, /branches/* like you normally do, all the developers usually work off /trunk anyways because /client changes are tied to /server and they have both checked out and they also need to read/update the docs common to the server and client. However, tags are deployed to separate machines and the docs don't need to be; so they're tagged separately off their respective working directories. So when git svn sees /tags/client_1.0, it'll think that it was tagged off /trunk and not /trunk/client. But since you're tracking /trunk and not /trunk/client, it can't find history in /trunk. So it starts tracking /trunk/client anew without taking /trunk into account. So git svn will create a ref that looks like tags/client_1.0@REV. What git svn could (and if somebody found time to work on it) is to reuse any/first tags/client_1.0@REV tags it finds. And simply using the existing git history of /trunk to see the history of /trunk/client is suboptimal, too, because /trunk/client could've originally come from /client (an actual case I've encountered) before /trunk existed. Remember, unlike SVN, git doesn't track directory renames (or renames, or directories at all) for that matter. This is a huge fundamental difference between the two systems and mapping between them was one of the greatest difficulties I had with git svn. The very first version of git svn was something that would only ever dumbly track one directory (and it still supports that mode of operation, just don't pass any options to init/clone). So a git working tree might have trunk, branches/*, tags/* all on the filesystem. It's a very big working tree in some cases, but it was the easiest to implement because it didn't do anything smart. -- 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