Will Palmer <wmpalmer@xxxxxxxxx> writes: > On Tue, 2010-10-19 at 12:12 +0530, Ramkumar Ramachandra wrote: > > 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 think there might be a problem in that in git commit is defined by its parents and its final state, while revision in Subversion is IIRC defined by change. Isn't it? -- Jakub Narebski Poland ShadeHawk on #git -- 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