On Tue, 2010-10-19 at 12:12 +0530, Ramkumar Ramachandra wrote: > Hi Stephen, > > Stephen Bash writes: ... > > > > I have 32 SVN revs in my history that touch multiple Git commit > > objects. The simplest example is > > svn mv svn://svnrepo/branches/badBranchName svn://svnrepo/branches/goodBranchName > > which creates a single SVN commit that touches two branches > > (badBranchName will have all it's contents deleted, goodBranchName > > will have an "empty commit" as described above). The more devious > > version is the SVN rev where a developer checked out / (yes, I'm not > > kidding) and proceeded to modify a single file on all branches in > > one commit. In our case, that one SVN rev touches 23 git commit > > objects. And while the latter is somewhat a corner case, the former > > is common and probably needs to be dealt with appropriately (it's > > kind of a stupid operation in Git-land, so maybe it can just be > > squashed). > > Ouch! Thanks for the illustrative example- I understand now. We have > to bend backwards to perform a one-to-one mapping. It's finally struck > me- one-to-one mapping is nearly impossible to achieve, and I don't > know if it makes sense to strive for it anymore. Looks like Jonathan > got it earlier. It's been a while since I was involved in this discussion, so maybe the design has changed by now, but I was under the impression that there would be one "one-to-one" mapping branch (which would never be checked out), containing the history of /, and that the "real" git branches, tags, etc, would be based on the trees originally referenced by the root checkout, with git-notes (or similar) being used to track the weirdness in mappings. How does the "multiple branches touched in a single commit" complicate anything other than the heuristics for automatic branch detection (which I assume nobody is at the stage of talking about yet). I suppose we wouldn't be talking, technically, about a one-to-one mapping in that case, as we would be turning "one" svn revision into "many" git branches, but in the conceptual sense of "one svn repository equals one git repository", I don't see this as being impossible, or so difficult that it shouldn't be striven-for. Something else which is at least semi-common in svn is to treat a folder both as a "directory" and a "branch", which the "checking out /" example would just be an extreme example of. Think in terms of git branches being a "view" of the history, with some mapper sitting between each view and "root" checkout. -- 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