hg bisect seems to fail

[Marcin Kasperski]

> Maybe I have a fundamental misunderstanding in how hg graph works.
> I thought that the local number is purely for convenience, 

Yes, it is.

> ordering of the changesets (if no hg-git is involved) is always the same
> for everybody

No, it isn't. Take simple case: you have two checkouts A, and B, in sync
so far:

          -A-               -B-
         [BASE]            [BASE]

You make commit in A, and another commit is made in B:

          -A-               -B-
         [BASE]            [BASE]
           X                 Y

You pull from B to A, and merge

          -A-               -B-
         [BASE]            [BASE]
           X                 Y
           Y
           M

You push to B

          -A-               -B-
         [BASE]            [BASE]
           X                 Y
           Y                 X
           M                 M

As you can see, X and Y are differently ordered (and have different numbers). 

This is the simplest example. In replicated public repo cases your
ordering may heavily depend on „where you pull from”. Or whether you
pulled from some „richer” repo at all.

Note: I mentioned those local numbers just as ilustration (as they
clearly showed the difference), trying to guess what could be a problem.

> So I interpret this as 856cce0c255c
> is the parent of 4394687b298b. 

It indeed is:
   ❯ hg parent -r 4394687b298b
   changeset:  43597:856cce0c255c
   branch:   stable


Sidenote: from the fact that in your checkout those changesets are together
I'd guess that you pulled only stable branch (at least at that moment).

So my guess was wrong and your bisect woes have different reason. As I
said previously, without session transcript it is difficult to analyze
them in detail.