[PATCH 3 of 6 V3] histedit: replace various nodes lists with replacement graph (and issue3582)

[Augie Fackler]

(responding on the list for posterity)
On Oct 10, 2012, at 3:59 AM, pierre-yves.david at logilab.fr wrote:

> @@ -140,30 +139,29 @@
>> pick d36c0562f908 1 c
>> pick 0efacef7cb48 3 f
>> pick ae467701c500 2 d
>> EOF
>   $ hg histedit 1 --commands commands.txt --verbose | grep histedit
> -  histedit: Should update metadata for the following changes:
> -  histedit: moving bookmarks five from 0efacef7cb48 to 1be9c35b4cb2
> +  histedit: moving bookmarks three from ae467701c500 to 1be9c35b4cb2
>   histedit: moving bookmarks four from ae467701c500 to 1be9c35b4cb2
> -  histedit: moving bookmarks three from ae467701c500 to 1be9c35b4cb2
> +  histedit: moving bookmarks five from 0efacef7cb48 to 7c044e3e33a9
>   saved backup bundle to $TESTTMP/r/.hg/strip-backup/ae467701c500-backup.hg (glob)
> 
> We expect 'five' to stay at tip, since the tipmost bookmark is most
> likely the useful signal.
> 
>   $ hg log --graph
>   @  changeset:   3:1be9c35b4cb2
> -  |  bookmark:    five
>   |  bookmark:    four
>   |  bookmark:    three
>   |  tag:         tip
>   |  user:        test
>   |  date:        Thu Jan 01 00:00:00 1970 +0000
>   |  summary:     d
>   |
>   o  changeset:   2:7c044e3e33a9
> +  |  bookmark:    five
>   |  user:        test
>   |  date:        Thu Jan 01 00:00:00 1970 +0000
>   |  summary:     f
>   |
>   o  changeset:   1:d36c0562f908


This change in test output isn't right: the workflow I use with histedit (which I should blog about) depends on tipmost bookmarks staying tipmost. I could be swayed that it's a defect for inactive bookmarks (I think), as that wouldn't break my particular workflow.

Other than that, this patch looks great, and I've queued the first two.