Convertion tools (GSoC 2009)

[Augie Fackler]

On Mar 24, 2009, at 3:40 PM, Abderrahim Kitouni wrote:

> Hi,
>
> I did more research on the subject, I downloaded dulwich and played
> with it in IPython,
> I think it is useable but needs some polishing (I found some technical
> documents about git
> [1] so that shouldn't be a problem), the wire protocol is therefore
> not a problem.
>
> So to be able to clone, we'll just need to convert git objects
> (commit, tree, blob, tag)
> and git refs correctly. The problem is that I don't know how to define
> "correctly"
> (for tags and refs), I think it should be a trade-off between "the
> user doesn't need to
> know he is using a git repo" and "the user should be able to know
> exactly how to get a
> given behaviour", looking at hgsubversion, it seems that it's doing  
> the second.

The second seems to be the path of least resistance to get going,  
although in the end (from experience) I think having --svn flags for  
push/pull/etc to make things more integrated and less odd feeling will  
be better. There are plans for hgsubversion to make a wrapper for the  
pull command so that if default is an svn url, hg pull just does the  
right thing. We're still nailing down the UI bits, and that could very  
well prove to be the Wrong thing as well.

Obviously, this is harder in one respect for git since --git already  
has a special meaning to hg, but easier in others since git is less  
alien than svn in a lot of ways (tags/branches are first class, not  
almost an afterthought).

> We'll also need to be able to keep git sha1 hashes (which I believe
> will be different from mercurial's in the case of commit, and the  
> other objects don't have exact
> counterparts), or to recompute them. Here again, I think dulwich will
> be able to get this done (or needs to be fixed :-)).

Yes, we'll need to recompute hashes, unless we could just "bolt on" a  
LocalGitRepository backend that abstracted away all the differences  
and used packs instead of revlogs for its actual backend, but that's  
probably much more ambitious than what you're talking about.

> To be able to push back to git (and this is, I believe, the trickier
> part), we'll need to generate git objects from whatever the user has
> committed to the repository. git isn't as limited as subversion, so
> this would require less work (e.g. rebasing isn't needed).

*nod* The issue (as I see it) is tracking the hash mapping, but given  
that we can do the commits a bit more cleanly in git (less screwing  
around with times  and authors changing) it should be possible without  
having to change the revision hash hg-side after every commit. It's  
possible that you could hook into the repo commit process, and do the  
commit on the git side first and then immediately convert to the hg  
format, since you'll already have a local repo. Then again, this may  
interact badly with extensions that rewrite history, so YMMV.

> I didn't elaborate on refs as I don't have a clear idea about what to
> do. Maybe the bookmarks extension can help here.

I think refs and remotes are probably bookmarks, yes.

> Anyway, I think the project (well, the part outlined above) is doable
> in a summer, but I'd prefer to have more opinions on this :-).

I'm glad to see someone so interested in a project like this.

Augie

> Regards,
> Abderrahim
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>