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

[Stephen Bash <bash@genarts.com>]

----- Original Message -----
> From: "Will Palmer" <wmpalmer@gmail.com>
> To: "Jakub Narebski" <jnareb@gmail.com>
> Sent: Thursday, October 21, 2010 5:08:17 AM
> Subject: Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)
> On Wed, 2010-10-20 at 22:44 +0200, Jakub Narebski wrote:
>
> It's tedious, but still fairly simple, to
> walk the history and build a new history consisting only of edits to a
> subtree (even if the commit messages don't always make sense out of
> context). It really doesn't matter one lick whether a single svn
> commit touched multiple generated git commits.

After reading your first entry into this thread, this is certainly what I was envisioning.  I'm still a little worried about initial clone size (over the weekend I had to wait over an hour for my full-svn-history git repository to clone from work to home), but it is certainly an intriguing idea.  With appropriate mapping information (copyfrom properties and some user input) I think you could create a very convincing Git history by creating commit objects using subtrees of the SVN-imported history.  I had been thinking about a very similar solution, but I was planning on pruning the original SVN-imported commit objects to save space...
 
> Of course, "ignoring merges" is temporary and a total cop-out

This is still bugging me...  Even with svn mergeinfo (which I think is a small percentage of the SVN revisions in the world), IMO an SVN merge is *not* a Git merge.  I think of it as a git cherry-pick (someone correct me if this mental model is wrong).  The key point in my mind is SVN merge doesn't have to merge the entire branch history.  Perhaps some heuristics can be applied in Git to decide if an SVN merge is a "true merge" or a cherry-pick?  But I have a nagging feeling that in the end the model mismatch is going to be very hard to overcome.

Thanks,
Stephen