[non topological heads] (was: resolved data corruption with convert, now I can't push)

[Matt Harbison]

On Thu, 01 Jun 2017 06:56:47 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

>
>    > On Wed, 31 May 2017 07:00:47 -0400, Uwe Brauer <oub at mat.ucm.es>  
> wrote:
>
>    > Isn't the clone that was the source of rsync still around?
>
> I checked my two laptops and the USB, unfortunately no, I don't have any
> clean clone. The data corruption must have occurred some days ago.
> Conclusion I never ever again will use rsync to copy a repo to a USB, I
> will use push instead.
>
>    > I think converting and ignoring errors is the Rambo solution. You
>    > could use 'incoming' from BB into the converted repo to count how  
> many
>    > BB commits got mangled. If there aren't many, maybe you don't care
>    > (though it would be recent). If there are many, that means the
>    > corruption occurred early on, not necessarily that there's something
>    > wrong with subsequent commits.
>
>
> Given that I don't posses a corruption free clone (save the 2 weeks old
> repo in bitbucket). I see the following solutions:

I've got to ask a stupid question, since IDK what the corruption is or  
where it is.  Can you clone from BB, and then from inside that local  
clone, pull from the corrupted repo?  Even if you can't pull everything,  
maybe you can specify a revision and pull in pieces at a time?

>     -  I use the converted repo, I delete the bitbucket repo, re-add
>        it and push from the converted. History is of course changed
>
>     -  or I clone the bitbucket one. I delete .hg in the converted one,
>        copy all files into the the bitbucket clone commit and push. I
>        will loose  the history of the last two weeks.
>
>     -  I clone the bibucket one, then I pull from the converted one and
>        try to merge. I did this, but when I push I sill receive
>        abort: push creates new remote head c698c52f6a03!. That head is
>        not a topological one, so I don't know what to do.

So, what's the child of this one?

>     -  I could try to run push -f
>
>     -  or I could try to merge that rev with tip as  well. I looked at  
> the
>        rev, it is from September last year and I don't understand
>        why it has a head. Most likely from the data corruption?
>
> Last comment: the bitbucket repo has 4 named branches
> year-2016-17                 518:7cdd8585c0ac
> default                      472:6004f738e2d5
> exam-geo2-2016-parts         456:adfdfc6ba6c5
> no-exam                      256:1888f9c19fce
>
> But five topological heads the 5th is
> changeset:   386:1aea182c63f3
> parent:      378:05af9bca5fae
>
> Which I don't understand frankly where that comes from.

Assuming that you didn't omit the branch name, it would seem that this is  
another head on default.  So it seems that somebody did a push -f at some  
point.

> The recovered one with convert has also 4 branches (the same as
> bitbucket, and 5 topological heads.
>
> But the one in which I merged the recovered one with the bitbucket, has
> these heads
>
>
> changeset:   585:c3ca8d2bfcd0
> branch:      exam-geo2-2016-parts
> user:        Uwe Brauer <oub at mat.ucm.es>
> date:        Thu Jun 30 16:14:23 2016 +0000
> summary:     Finish publishing notas
>
> changeset:   456:adfdfc6ba6c5
> branch:      exam-geo2-2016-parts
> user:        Uwe Brauer <oub at mat.ucm.es>
> date:        Thu Jun 30 16:14:23 2016 +0000
> summary:     Finish publishing notas
>
> What the heck happened here?

So, what likely happened is that when you converted, ignoring the errors  
that would have occurred reading certain files caused those files to be  
skipped in a problem commit.  This changed the hash for the commit.  Since  
part of the hash is the hash of the parent(s), the subsequent commit  
hashes are also changed.  The diff-to-parent for both of these is probably  
the same.  That's why I mentioned using incoming and outgoing to see where  
the corruption occurred.

I would probably figure out where the corruption occurred first- is it in  
some commit that you already have on BB?  It would seem so, otherwise you  
should just be able to pull in the converted repo, and not have anything  
to merge.  Then, you might just be able to rebase just what you need to  
add to BB, and finally strip out the rest of the converted commits.

> Also it confuses me that when pushing hg complains about
> rev c698c52f6a03! That is a head but not a topological one.
> I thought I understand the graphs and the heads but I don't. Is the non
> topological head harmful?

I don't understand.  `hg help glossary` says a topological head is a  
commit with no children.  How can something be a head but not a  
topological head?

>  I swore I will never use rsync for repos again
>
> Thanks
>
> Uwe Brauer
>