Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

> 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).