hg bisect seems to fail

[Uwe Brauer]

>>> "MK" == Marcin Kasperski <Marcin.Kasperski at mekk.waw.pl> writes:

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

Ok, I subconsciously did not think of pushing since I don't have write
access, but you are of course right, so even in your example 

Hg parent -r M would give different answers. I never thought about that,
thanks for pointing that out.

I will keep an eye on bisect I usually use it for small repos (converted
from git) but sometimes for GNU Emacs (which of course is also converted
from git).

Uwe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5673 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20200131/52f533da/attachment.p7s>