Erreur Mercurial: le référentiel n'est pas lié

Je viens de commencer avec Mercurial, j'ai un référentiel `` central '' sur Bitbucket que j'ai cloné sur une machine et apporté des modifications et validé et poussé. J'ai ensuite cloné depuis Bitbucket vers une autre machine engagée et poussée, ce qui était bien. Je suis ensuite revenu sur la première machine, j'ai apporté des modifications et tenté de pousser, mais j'ai reçu le message d'erreur. Qu'est-ce que je fais mal? Aurais-je dû tirer en premier? Comment puis-je résoudre l'erreur et pousser? Toute aide est appréciée!

Darren.

mercurialdvcsbitbucket

5 sept. 2011iamdarrenhall

Un référentiel Mercurial obtient son identité lorsque vous y effectuez le premier commit. Lorsque vous créez un nouveau référentiel sur Bitbucket, vous créez un référentiel vide sans identité.

Lorsque vous clonez ce référentiel sur la machine A et effectuez une validation et le repoussez, vous marquez le référentiel. Si vous avez cloné le référentiel sur la deuxième machine avant en poussant depuis la première, vous pouvez vous retrouver dans la situation que vous décrivez.

Veuillez exécuter hg paths sur la machine sur laquelle vous ne pouvez pas pousser. Faites ensuite un clone distinct du référentiel sur lequel il indique qu'il va pousser. Examinez maintenant le premier ensemble de modifications dans chaque référentiel avec

hg log -r 0

Si les modifications initiales sont différentes, vous disposez de deux référentiels non liés, comme nous l'appelons dans Mercurial. Vous pouvez ensuite exporter les modifications que vous ne pouvez pas envoyer sous forme de patchs et les importer dans l'autre.

6 sept. 2011Martin Geisler

Si vous êtes presque sûr que le chemin de transmission est correct, il peut être utile d'exporter simplement vos modifications dans les correctifs à partir du référentiel de problèmes, de les cloner à nouveau à partir de Bitbucket, puis d'importer les correctifs dans le nouveau référentiel. Cela fonctionnera ou révélera un commit mauvais/corrompu.

5 sept. 2011bressain

Je voudrais partager des connaissances sur les internes Mercurial.

Les référentiels ne sont pas liés lorsqu'ils n'ont pas les mêmes révisions.

Pièce correspondante que vous pouvez trouver dans Mercurial/treediscovery.py:

base = list(base)
if base == [nullid]:
    if force:
        repo.ui.warn(_("warning: repository is unrelated\n"))
    else:
        raise util.Abort(_("repository is unrelated"))

base est une liste de racines de parties communes dans les deux référentiels locaux/distants.

Vous pouvez toujours savoir en quoi les référentiels sont différents en:

$ hg in $REMOTE
$ hg out $REMOTE

Vous pouvez toujours vérifier les racines des deux (après avoir cloné les deux localement):

$ hg -R $ONE log -r "roots(all())"
$ hg -R $TWO log -r "roots(all())"

si la sortie des commandes ci-dessus ne partage pas d'ID - ces référentiels ne sont pas liés. En raison des propriétés de hachage , il est très impossible que les racines soient égales accidentellement. Vous ne pouvez pas tromper la vérification des racines en créant soigneusement des référentiels car la construction de deux référentiels ressemble à ceux-ci (avec des parties communes mais des racines différentes):

0 <--- SHA-256-XXX <--- SHA-256-YYY <--- SHA-256-ZZZ
0 <--- SHA-256-YYY <--- SHA-256-ZZZ

impossible car cela signifie que vous inversez SHA-256 car chaque hachage suivant dépend des valeurs précédentes.

Ayant ces informations, je pense que tous les développeurs sont capables de dépanner error: repository is unrelated.

Voir aussi Identification du référentiel Mercurial

Merci de votre attention, bon piratage!

23 oct. 2015gavenkoa

Vous obtenez ce message lorsque vous essayez de pousser vers un référentiel autre que celui que vous avez cloné. Vérifiez l'adresse du Push ou le chemin default, si vous utilisez simplement hg Push par lui-même.

Pour vérifier le chemin par défaut, vous pouvez utiliser hg showconfig | grep ^paths\.default (ou juste hg showconfig et recherchez la ligne qui commence paths.default=).

5 sept. 2011harpo