Re: git mirror

[Derek Fawcus]

On Wed, Feb 15, 2012 at 12:00:14PM +0100, Ivan Vu??ica wrote:
> hg-git is actually syncing hg and git repositories, so it can be used to 
> import hg into git as well.

As I understand it,  any means of syncing other content in to git
(such that git is not the 'master') suffers from the same limitation
as git-svn.

Namely that history appears to change for the last few commits
when the round trip of git->other->git completes.  This is down
to git being content addressable using a crypto hash,  and that
the various schemes add extra data in to the commit record.

Which is why such schemes then enforce a requirement that one
rebase work when updating from the 'master'.

So I read hg-git as allowing natural use of hg to access git
repositories.  But I'd expect if one was using it to try and
achieve natural git client access to a hg repository (if that
is what you're suggesting),  that it would suffer from the
same issue with history (from the git client perspective)
appearing to change,  and hence forcing rebases.

I thought hg also used crypto hashs,  but the suggestion with
hg-git is that when hg is the 'slave',  the hg view does not
get messed up during the hg->git->hg round trip.

If true then I guess that would mean that hg doesn't use the
hash as the core underlying id,  and hence that slaving hg
to git would give the most satisfactory experience to all
users?

i.e. master on github,
      +  svn access to the master via the facility that github provides
      +  people desiring to use hg make use of the hg-git plugin

Then the only constraint would be that octopus merges within git
should be avoided,  as hg cannot accurately represent them.

Then additional locations could maintain git clones.  The only
effect of github downtime being that svn access would be unavailable,
whereas git and hg access to the clones would still be available.

.pdf