hg bisect seems to fail

Uwe Brauer oub at mat.ucm.es
Thu Jan 30 09:45:19 UTC 2020


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

   >> The first bad revision is:
   >> changeset:   43430:4394687b298b
   >> branch:      stable
   >> tag:         bad
   >> user:        Pierre-Yves David <pierre-yves.david at octobus.net>
   >> date:        Sat Nov 16 20:07:49 2019 +0100
   >> summary:     pure: use string for exception in the pure version of base85

   > Considering you faced some string/bytes-related problem under py3,
   > mayhaps this is the very version which accidentally changed sth what
   > impacted the problem. Or mayhaps this change caused recompilation of sth
   > left uncompiled by accident.

   >> That is nonsense, the wrong branch, and if you checkout the changeset
   >> before, it does not compile neither.

   > In heavily merged history bisect travels via various paths, trying to
   > find sth sensible. 

Ok.

   > Not sure what you mean by „changeset before”, but it
   > can be on another branch which got the same or similar change etc.

Oh, I meant the parent.


   > In my checkout this changeset's parent is ~70 commits back and sideways
   > there are commits from other branches:

   >     hg log -r 4394687b298b
   >     changeset:   43666:4394687b298b
   >     branch:      stable
   >     parent:      43597:856cce0c255c
   >     user:        Pierre-Yves David <pierre-yves.david at octobus.net>
   >     date:        Sat Nov 16 20:07:49 2019 +0100
   >     summary:     pure: use string for exception in the pure version of base85

   > (note 43666 vs 43597) so if you mayhaps tried 43665 (43429 in your
   > checkout), it was unrelated commit from another branch.

Maybe I have a fundamental misunderstanding in how hg graph works.
I thought that the local number is purely for convenience, but the
ordering of the changesets (if no hg-git is involved) is always the same
for everybody, so in my graph I see
o | | | |  changeset:   43430:4394687b298b
|/ / / /   Branch:      stable
| | | |    user:        Pierre-Yves David <pierre-yves.david at octobus.net>
| | | |    Date:        Sat, 16 Nov 2019 20:07:49 +0100
| | | |    Phase:       public
| | | |    summary:     pure: use string for exception in the pure version of base85
| | | |
o | | |  changeset:   43429:856cce0c255c
| | | |  Branch:      stable
| | | |  user:        Denis Laxalde <denis.laxalde at logilab.fr>
| | | |  Date:        Tue, 12 Nov 2019 11:05:03 +0100
| | | |  Phase:       public
| | | |  summary:     py3: avoid iterating over a literal bytes in highlight
| | | |

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

If I understand you correctly 856cce0c255c is not the parent and I
checked then the wrong changeset, but then 



hg parent -r 43430
tells me 43429

Which is precisely what I tried. 

I am now totally confused. What would have been the correct strategy to
find out the parent of 43430 which was marked as the first bad
changeset?


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/20200130/7d346050/attachment.p7s>


More information about the Mercurial mailing list