On Wed, 2010-10-20 at 04:59 -0700, Jakub Narebski wrote: > 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? > A "change" is a delta between one state and another, so each revision is dependent on those which came before it just as much as a a git commit is. An svn "revision" is a snapshot, regardless of how it is stored, ie, the "svn stores changes, git stores snapshots" is an implementation detail. It's a detail which makes a lot of things easier/faster in git than they would be in svn, but a mere detail none the less. The difference of course is that the "name" of an svn revision stays the same even if aspects of that revision (for example, the commit message) are changed, while the "name" of a git commit is dependent on everything that makes up a commit. In git terms, changing a commit message is considered to be history rewriting, whereas in svn terms it is merely something which happens occasionally as part of regularly maintained repository. the git Philosophy is ingrained in its object model: If you change something which led to a state, you change the state itself. I don't think there should be an attempt to work-around that philosophy when talking to external repositories. That is to say: if a commit message (or other revprop) in history changes, we want to treat it as if we were recovering from an upstream rebase. Of course, a problem in that could very well be "how would we know about it?", which is a good question, but one not directly related to [revision+directory]<->[commit] mappings, afaik ;) -- 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