Re: git mirror

[Derek Fawcus]

On Wed, Feb 15, 2012 at 03:17:08PM +0100, Ivan Vu??ica wrote:
> 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.

(This is probably off topic to most people...)

Well,  history in git is immutable - but that is a consequence of the hash.

What happens is that one can start a new branch from an arbitrary point
in the histroy DAG,  and choose to adjust references after the fact,
allowing symbolic names (branches,  unsigned tags) to refer to the new point.

[Having moved references,  one can discard the old history;  but that is
 when problems will occur if it has been distributed]

These seperate histories have seperate hashs (otherwise the 'new' one would
have simply be indistinguishable from the 'old').

So if when syncing between seperate VCS,  any change occurs to the git data
a new branch appears.  If one has futher work based on your original pushed
branch,  it has to be rebased.  Hence history is locally seen to move.

The implication being that if (non native) round trip syncing between a
slave git repository and some other type of repository is to occur,
the metadata to achive that must not be part of the inherent git content
being synced.  (i.e. the commit messages as in git svn).

Maybe hg-git does this and stores metadata seperate from the history
DAG being synced (say in a multi rooted DAG?).

As you imply,  maybe this part of the hg implementation has more flexibility
allowing it to cope with what would upset git.

.pdf