two heads have no common ancestor

[D Wang]

On Thu, Jan 30, 2014 at 11:37 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2014-01-30 at 15:38 -0500, D Wang wrote:
>> Hello hg devs,
>>
>> I have a repo where the two heads have no common ancestor, which I
>> thought was impossible.  How could I have gotten myself into this
>> state, and is there any clever way to merge these two heads short of
>> manually examining each file?
>>
>> (Please cc dwang at janestreet.com on replies because I am not subscribed
>> to the mailing list.)
>>
>> $ hg heads --template '{node|short} {date|isodate} ({parents}) {tags} \n'
>> 520c0024b6e1 2014-01-30 14:30 -0500 () tip
>> 76d5d232371f 2014-01-24 13:11 -0500 ()
>> $ hg log -r 'ancestor(520c0024b6e1,76d5d232371f)'
>> $ hg log -G -r 'ancestors(520c0024b6e1)' --template '{node|short}
>> {date|isodate} ({parents}) {tags}\n'
>> @  520c0024b6e1 2014-01-30 14:30 -0500 () tip
>> |
>> o  1628b6cba1b6 2014-01-29 19:57 -0500 ()
>> |
>> o  061c697ef8e7 2014-01-28 20:29 -0500 ()
>> |
>> o  2c06ad30d497 2014-01-27 19:40 -0500 ()
>> |
>> o  02ab4c712c43 2014-01-26 20:00 -0500 ()
>> |
>> o  557d342a24c6 2014-01-25 20:09 -0500 ()
>> |
>> o  2b94d7ce938f 2014-01-24 20:07 -0500 ()
>> |
>> o  7c6911410f0b 2014-01-24 14:05 -0500 ()
>> |
>> o  0f7b23a5ddaa 2014-01-24 13:11 -0500 (-1:000000000000 )
>>
>> 0f7b23a5ddaa has exactly one parent, the all-zeroes revision:
>>
>> $ hg log -r 0f7b23a5ddaa --debug
>> changeset:   671130:0f7b23a5ddaa899812f9163828a287ae8122630d
>> parent:      -1:0000000000000000000000000000000000000000
>> parent:      -1:0000000000000000000000000000000000000000
>> manifest:    671129:d33e6dea36c0a404f162ed8f802f8d933f4d656c
>> ...
>
> Most likely way this happened is that your .hg/dirstate got nuked by
> forces unknown:
>
> $ hg sum
> parent: 20467:a959f7167077 tip
>  clone: do not turn hidden changeset public on publishing clone
> (issue3935)
> branch: stable
> bookmarks: *@
> commit: 18 unknown (clean)
> update: (current)
> mq:     9 unapplied
> $ mv .hg/dirstate{,-mangled}
> $ hg sum
> parent: -1:000000000000  (no revision checked out)
> branch: stable
> commit: 1054 unknown (new branch)
> update: 20333 new changesets (update)
> mq:     9 unapplied
>
> A commit here is perfectly valid.
>
> Also, if your dirstate gets corrupted, you might get a message like
> this:
>
> $ hg sum
> warning: ignoring unknown working parent 7859f7167077!
> parent: -1:000000000000  (no revision checked out)
> branch: stable
> commit: 18 unknown (new branch)
> update: 20333 new changesets (update)
> mq:     9 unapplied
>
> This is only a warning, because people found that when it was a fatal
> error, they were unable to recover without expert help because just
> about every command failed.
>
>> Unfortunately, the contents of this repo are machine-generated, so
>> it's not easy to figure out the relationship between these revisions
>> by reading the files.
>
> ..and an automated process might ignore that warning.
>
> But if this is an automated process, you may be able repair the
> situation with a rebase.

We ended up just exporting a snapshot of the working directory and
commiting it into a brand-new repo.  This makes sense in the context
of some historical design decisions for this system.

>> Unfortunately, this is a repo where almost all the commits are made by
>> an automated system, so I don't what commands were run and it's
>> entirely possible we did something absurd.
>
> You might want to checkout the blackbox extensions.

Ah, that reminds me I have to construct a good test case for a problem
which prevents us from upgrading to hg-2.7.  We are issuing some
sequence of commands (or maybe just enough commands?) that causes each
hg-2.7 command server process to allocate 5GB.  Unfortunately, I
haven't yet reproduced this behavior outside the context of this
somewhat crazy system and its similarly crazy repo contents.

Unless blackbox is available for 2.3?

Wang