On Wed, Feb 15, 2012 at 14:20, Derek Fawcus
<dfawcus+lists-gnustep-discuss@employees.org> wrote:
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?
hg does use a hash, and I am not really sure what sort of arcane trickery hg-git folks employed, but it seems to work pretty well for me, at least as much as I used it.
I suspect that, since hg treats history as immutable (and it should probably be treated the same with git, no matter what anyone says), it is easy to "get the correct hash for the other system", and hence uniquely map individual commits appropriately. And hg-git probably separately tracks any additional required-but-unmappable attributes.
If we opt for a DVCS (which I really think we should), I don't really think the choice between hg and git is important for the server-side storage. It'll be felt on the user side: users of the "other" system will have to also get hg-git or a similar tool, and compiling hg-git may be non-trivial on some systems.
On the other hand, it's easy to provide a secondary repository based on the secondary DVCS, from which the commits will be imported into the primary repository and primary DVCS.