• Community
  • Questions
  • Comparing a forked bitbucket repository to the original: xxxxxxxxxxxx & 000000000000 are unrelated. Why?

Comparing a forked bitbucket repository to the original: xxxxxxxxxxxx & 000000000000 are unrelated. Why?

As a follow up to How to push from a bitbucket repository to a bitbucket repository, and after reading Fork a Repo, Compare Code, and Create a Pull Request these steps somehow fail:

  1. Fork https://bitbucket.org/NickHodges/codingindelphi into https://bitbucket.org/jeroenp/codingindelphi
  2. Clone https://bitbucket.org/jeroenp/codingindelphi locally using TortoiseHG
  3. Add a .hgignore file in the root of the local clone
  4. Commit into the local clone
  5. Push the local clone to https://bitbucket.org/jeroenp/codingindelphi
  6. Compare https://bitbucket.org/jeroenp/codingindelphi/compare
  7. Result is 0a23cca9cf3c & 000000000000 are unrelated.

I expected the compare to succeed. Why does it fail?

In addition, I tried to do a pull request from jeroenp to NickHodges via https://bitbucket.org/jeroenp/codingindelphi/pull-request/new It takes forever without completing.

Why doesn't it complete? And how can I make it complete?


2 answers

1 accepted


https://bitbucket.org/NickHodges/codingindelphi/src is completely empty. There is nothing to compare the fork with the original. Once the original has at least an initial commit, things will work as you expect.

--Marcus Bertrand / Bitbucket


Since I'm not only interested in the 'how to solve this', but also on the 'why did this fail'.

Please correct any observations / reasoning I make during my search for the 'why':

C:\temp>hg id -i -r0 --debug https://bitbucket.org/jeroenp/CodingInDelphi


C:\temp>hg id -i -r0 --debug https://bitbucket.org/NickHodges/CodingInDelphi

It looks like - even though the first is a clone from the second - their root revision IDs differ, which raises the question: why do they differ?

So I looked at the local logs (too bad you cannot perform a log on a remote repository):

C:\Users\Developer\HG\bitbucket.org\jeroenp\CodingInDelphi>hg log -r0 --debug
changeset:   0:0a23cca9cf3c87f72e48aa54c06a9f45aed1c94d
tag:         tip
parent:      -1:0000000000000000000000000000000000000000
parent:      -1:0000000000000000000000000000000000000000
manifest:    0:5c29c39f91a382ca4abb38fcf5dfd08e3fb75407
user:        ...@...
date:        Wed Jul 17 15:45:25 2013 +0200
files+:      .hgignore
extra:       branch=default


C:\Users\Developer\HG\bitbucket.org\NickHodges\CodingInDelphi>hg log -r0 --debug
changeset:   -1:0000000000000000000000000000000000000000
tag:         tip
parent:      -1:0000000000000000000000000000000000000000
parent:      -1:0000000000000000000000000000000000000000
manifest:    -1:0000000000000000000000000000000000000000
date:        Thu Jan 01 00:00:00 1970 +0000
extra:       branch=default

I think it has to do with the nullid nodeid.

(continued in next comment...)

(... continued from previous comment because of the 2000 character limitation)

Somehow for an empty repository, the first revision not only points to null, but is null as well, which means the repository also has a nullid as ID.

As soon as you commit your very first change to an empty repository, the first revision itself is changed to point to a hidden null revision:

  1. it is assigned an ID different from nullid.
  2. it gets a manifest ID different from nullid.
  3. it gets a user different from the empty user.
  4. it gets a date (actually: timestamp) different from the null unix time.

Finally, I found out the empty repository cannot be tagged. Since r0 has nullid for changeset/manifest, it is indeed called null revision:

C:\Users\Developer\HG\bitbucket.org\NickHodges\CodingInDelphi>hg tag -r0 identity
abort: cannot tag null revision

I think it would be wise to add a warning in bitbucket somewhere that if you clone an empty revision, that this is unwise to do so as you cannot compare it to the original, nor perform pull requests.


We're going to prevent users from being able to fork an empty repotiory. You are very correct that if you make a commit in both of the repositories independently, the two repositories won't be related and you'll never be able to perform a Pull Request between them. We've opened two tickets to fix and prevent this faulty behavior:

To fix this: commit a change to the NickHodges repository. If the jeroenp repository already has a file: make a backup (otherwise you get messages like "Unable to merge: Unrelated branches"). Delete the jeroenp repository, then build it from scracth (fork, commit changes, compare, create pull requests).

Suggest an answer

Log in or Join to answer
Community showcase
Jason Wong
Published yesterday in Agility Beta

Welcome to agility

Every team in the world is unique, and so   Atlassian believes   that each and every team's best way of working  needs to  be molded to their unique circumstances  – ...

351 views 6 15
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot