disappearing divergence state?

[Matt Harbison]

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
   $ hg -R clone sum
   parent: 5:f4df58a71d59
    second change
   branch: default
   commit: (clean)
   update: 2 new changesets, 2 branch heads (merge)
   phases: 2 draft
   unstable: 1 changesets
   divergent: 1 changesets
   unstable: 1 changesets
   divergent: 1 changesets

   $ hg -R clone log -r 'troubled()'
   5:f4df58a71d59b27ebcedb63d13ac164e6c485c97 second change (unstable  
divergent)