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