disappearing divergence state?

[Pierre-Yves David]

On 01/15/2016 06:49 PM, Matt Harbison wrote:
> On Fri, 15 Jan 2016 14:19:48 -0500, Matt Mackall <mpm at selenic.com> wrote:
>
>> On Mon, 2016-01-04 at 21:42 -0500, Matt Harbison wrote:
>>> I'm not sure what is going on here, so I thought I solicit debugging
>>> ideas.
>>>
>>> Based on timestamp and the lack of a corresponding email CC'd to my
>>> inbox, I must have used pushgate to submit this series.  I haven't
>>> noticed an issue with pushgate before though.
>>>
>>>
>>> https://selenic.com/pipermail/mercurial-devel/2015-December/076969.html
>>>
>>> When I got back to work and pulled today, the successors were in the
>>> transfer, and these 3 commits were marked "unstable, divergent".  The
>>> thg graph didn't give any clues about successors, so I tried `hg
>>> debugobsolete $orig_node`.  It cranked away for a few seconds, and
>>> exited without printing anything.  At that point, I noticed that
>>> $orig_node was now changed to "obsolete", and no longer divergent or
>>> unstable.  `hg log -r divergent()` printed the remaining 2 nodes, so
>>> this wasn't a transient or thg issue.
>>>
>>> Any idea what is going on here?  I have the latest default, and
>>> evolve should be no more than 3 weeks old or so.  I repeated `hg
>>> debugobsolete` on the second commit, and the same thing happened.
>>> Therefore, there's one left to experiment on (I suppose I could
>>> backup obsstore, anything else?)
>>>
>>>  From what I can tell, there is no actual divergence.  Locally, the
>>> affected commits are:
>>>
>>> $ hg log -r 28448::
>>> changeset:   28448:980d61134536
>>> user:        Matt Harbison <matt_harbison at yahoo.com>
>>> date:        Wed Dec 16 13:33:43 2015 -0500
>>> summary:     windows: correct the import of win32
>>
>> Locally, I've got:
>>
>> $ hg log -r "91225 or 223e" --hidden
>> changeset:   33152:912255f8f087
>> user:        Matt Harbison <matt_harbison at yahoo.com>
>> date:        Wed Dec 16 13:33:43 2015 -0500
>> summary:     windows: correct the import of win32
>>
>> changeset:   33145:223e8c7fc637
>> user:        Matt Harbison <matt_harbison at yahoo.com>
>> date:        Wed Dec 16 13:33:43 2015 -0500
>> summary:     windows: correct the import of win32
>>
>> ..where the first one is public and the second one is obsolete.
>>
>> I don't have a marker for your 980d hash, but it seems correct that it's
>> obsolete given that a public version of it exists.
>
> Here's a script that demos the problem.  IIRC, what happened is I made
> the fix and submitted it, but it didn't show up in the next pull.  So I
> rebased without thinking to run tests, since not even `hg version`
> worked without it.  It should be divergent after the pull (I think), but
> notice how debugobsolete changes the state of what it is run on.
>
> I've got hg 63116d47cc3f and evolve 4f83b2d2d20d locally.  I can file a
> bug if it's not just a misunderstanding on my part, but it is only a
> debug command.  I can't tell if there's a deeper issue though.
>
>    $ cat >> $HGRCPATH << EOF
>    > [ui]
>    > logtemplate = {rev}:{node} {desc} ({troubles})\n
>    > [extensions]
>    > rebase =
>    > evolve = C:\Users\Matt\Projects\hg-evolve\hgext\evolve.py
>    > EOF
>
> Baseline repo with Windows broken
>    $ hg init main
>    $ echo "baseline" > main/foo.txt
>    $ hg -R main ci -Aq -m "baseline"
>
> Fix the world change made locally, plus some other stuff
>    $ hg clone -q main clone
>    $ echo "fixed" > clone/bar.txt
>    $ hg -R clone ci -Aq -m "fixed"
>    $ hg -R clone export --git . > patch.diff
>    $ echo "another change" > clone/bar.txt
>    $ hg -R clone ci -q -m "second change"
>    $ hg -R clone export --git . > patch2.diff
>
> Upstream changes more without applying the patch, so pull and rebase to
> test more
>    $ echo "more changes" > main/foo.txt
>    $ hg -R main ci -q -m "more changes"
>    $ hg -R clone -q pull
>    $ hg -R clone rebase -s '.^' -d tip
>    rebasing 1:2b3e5a84160b "fixed"
>    rebasing 2:a4ded3c82426 "second change"
>
> Now import the original patch in main.  Diverge is to be expected after
> pull
>    $ hg -R main import --obsolete patch.diff
>    applying patch.diff
>    $ hg -R main import --obsolete patch2.diff
>    applying patch2.diff
>    $ hg -R clone -q pull
>    2 new divergent changesets
>
>    $ hg -R clone log -G
>    o  7:230312cef20bae271bdcc32b8efc6d667a93f311 second change ()
>    |
>    o  6:8850b598bd90d445576c83f3b256ec17516ec9f2 fixed ()
>    |
>    | @  5:f4df58a71d59b27ebcedb63d13ac164e6c485c97 second change
> (divergent)
>    | |
>    | o  4:5cdf8d052c4cd42c088fee9743d4411657e7b892 fixed (divergent)
>    |/
>    o  3:cb7e9b223c7a6baf2007b028a5ca1a3007b1ad4d more changes ()
>    |
>    o  0:770519deaae84c180cd02ecd3519ee5e8e4c5290 baseline ()
>
>    $ hg -R clone sum
>    parent: 5:f4df58a71d59
>     second change
>    branch: default
>    commit: (clean)
>    update: 2 new changesets, 2 branch heads (merge)
>    phases: 2 draft
>    divergent: 2 changesets
>    divergent: 2 changesets
>
>    $ hg -R clone log -r 'troubled()'
>    4:5cdf8d052c4cd42c088fee9743d4411657e7b892 fixed (divergent)
>    5:f4df58a71d59b27ebcedb63d13ac164e6c485c97 second change (divergent)
>
> debugobsolete seems to swallow the divergence
>
>    $ hg -R clone debugobsolete 5cdf8d052c4cd42c088fee9743d4411657e7b892

1) debugobsolete is not doing anything regarding divergence.
2) the command above is just creating an obsolescence marker (with no 
successors) over and over. That is probably not what you want to do.

-- 
Pierre-Yves David