comparison tests/test-treemanifest.t @ 31294:c134a33b1d73

treemanifest: make node reuse match flat manifest behavior

In a flat manifest, a node with the same content but different parents is still
considered a new node. In the current tree manifests however, if the content is
the same, we ignore the parents entirely and just reuse the existing node.

In our external treemanifest extension, we want to allow having one treemanifest
for every flat manifests, as a way of easeing the migration to treemanifests. To
make this possible, let's change the root node treemanifest behavior to match
the behavior for flat manifests, so we can have a 1:1 relationship.

While this sounds like a BC breakage, it's not actually a state users can
normally get in because: A) you can't make empty commits, and B) even if you try
to make an empty commit (by making a commit then amending it's changes away),
the higher level commit logic in localrepo.commitctx() forces the commit to use
the original p1 manifest node if no files were changed. So this would only
affect extensions and automation that reached passed the normal
localrepo.commit() logic straight into the manifest logic.

31293:2cdb1239ff8c

  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)
  (run 'hg heads' to see heads, 'hg merge' to merge)

31294:c134a33b1d73

  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)
  (run 'hg heads' to see heads, 'hg merge' to merge)

Committing a empty commit does not duplicate root treemanifest
  $ echo z >> z
  $ hg commit -Aqm 'pre-empty commit'
  $ hg rm z
  $ hg commit --amend -m 'empty commit'
  saved backup bundle to $TESTTMP/grafted-dir-repo-clone/.hg/strip-backup/cb99d5717cea-de37743b-amend-backup.hg (glob)
  $ hg log -r 'tip + tip^' -T '{manifest}\n'
  1:678d3574b88c
  1:678d3574b88c
  $ hg --config extensions.strip= strip -r . -q