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?


  1. Jeroen Pluimers

    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).

CommentAdd your comment...

1 answer



    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

    1. Jeroen Pluimers


      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':


      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):


      I think it has to do with the nullid nodeid.

      (continued in next comment...)

    2. Jeroen Pluimers

      (... 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:

      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.


    3. Marcus Bertrand

      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:

    CommentAdd your comment...