35

I've just started with Mercurial, I have a 'central' repository on Bitbucket which I cloned onto one machine and made changes and committed and pushed. I then cloned from Bitbucket to another machine committed and pushed which was fine. I then came back to the first machine, made changes committed and attempted to push, but got the error message. What am I doing wrong? Should I have pulled first? How can I resolve the error and push? Any help is appreciated!

Darren.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
frontendbeast
  • 1,043
  • 4
  • 13
  • 28

4 Answers4

38

A Mercurial repository gets its identity when you make the first commit in it. When you create a new repository on Bitbucket, you create an empty repository with no identity.

When you clone this repository to machine A and make a commit and push it back, then you brand the repository. If you have cloned the repository on the second machine before pushing from the first, then you can end up in the situation you describe.

Please run hg paths on the machine where you cannot push. Then make a separate clone of the repository it says it will push to. Now examine the first changeset in each repository with

hg log -r 0

If the initial changesets are different, then you have two unrelated repositories, as we call it in Mercurial. You can then export the changes you cannot push as patches and import them in the other.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
  • That must be it, I didn't push from the first machine. So I'm guessing I need to clone from Bitbucket back to machine A, and get rid of the old one. I take it I can work the way I am doing, on two machines, and this is just because I essentially had two revision zeros? – frontendbeast Sep 06 '11 at 08:42
  • Yes, I think you created two unrelated repositories by accident by making two different zero revisions. After you make the first commit and push it back to Bitbucket, then you can of course keep working on two machines. – Martin Geisler Sep 06 '11 at 09:31
  • We had a similar issue and the only solution was to start over forking and cloning again. It happened because we didn't initialize the main repository and there was not any way to fix it. – Maximiliano Rios Nov 26 '13 at 14:43
  • what do you mean "run hg paths"? how can I execute this? – creator Jan 19 '16 at 05:01
  • @leegod: Mercurial has a `paths` command, just like it has a `commit` and a `status` command. So open a terminal and run `hg paths` from within the working copy of your repository. – Martin Geisler Jan 19 '16 at 17:04
3

I would like to share knowledge about Mercurial internals.

Repositories unrelated when they have no any same revisions.

Corresponding piece you can find in 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 is a list of roots of common parts in both local/remote repositories.

You always may know how repositories are different by:

$ hg in $REMOTE
$ hg out $REMOTE

You always may checks roots of both (after cloning both locally):

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

if output from above commands doesn't share IDs - those repositories are unrelated. Due to hash properties it is very impossible that roots be equal accidentally. You may not trick roots checking by carefully crafting repositories because building two repositories looks like these (with common parts but different roots):

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

impossible because that mean you reverse SHA-256 as each subsequent hash depends on previous values.

Having this info I believe any Devs be able to troubleshoot error: repository is unrelated.

See also Mercurial repository identification

Thanks for attention, good hacking!

Community
  • 1
  • 1
gavenkoa
  • 45,285
  • 19
  • 251
  • 303
3

If you're pretty sure the push path is correct, it may be worth it to just export your changes to patches from the problem repo, clone again from Bitbucket and then import the patches into the new repo. This will either just work or reveal a bad/corrupted commit.

bressain
  • 899
  • 9
  • 20
1

You get this message when you try to push to a repository other than the one that you cloned. Double-check the address of the push, or the default path, if you're just using hg push by itself.

To check the default path, you can use hg showconfig | grep ^paths\.default (or just hg showconfig and look for the line that starts paths.default=).

harpo
  • 41,820
  • 13
  • 96
  • 131