revert: use modified information from both statuses Using status information against the target ensures we are catching all files with modifications that need reverting. We still need to distinguish fresh modifications for backup purpose. test-largefile is affected because it reverted a file that needs no content change.

revert: drop special case handling for file unknown in parent We had a special case for file not caught by any categories. It was aimed at files missing in wc and wc's parent but existing in the target revision. This is now properly handled using status information.

revert: use "remove" information from both statuses Using status information against the target to make sure we are catching all files that need to be re-added. We still need to distinguish fresh removal because they use a different message.

revert: process removed files missing in target as clean If a file does not exist in target and is marked as removed in the dirstate, we can mark it as clean. There are no changes needed to revert it.

revert: also track clean files Tracking clean files is the simplest way to be able to reports files that need no changes. So we explicitly retrieve them. This fixes a couple of test outputs where the lack of changes was not reported.

revert: triage "deleted" files into more appropriate categories Status can return file as "deleted". This is only a special case related to working directory state: file is recorded as tracked but no file exists on disk. This will never be a state obtainable from manifest comparisons. "Deleted" files have another working directory status shadowed by the lack of file. They will -alway- be touched by revert. The "lack of file" can be seen as a modification. The file will never match the same "content" as in the revert target. From there we have two options: 1. The file exists in the target and can be seen as "modified". 2. The file does not exist in the target and can be seen as "added". So now we just dispatch elements from delete into appropriate categories.

unshelve: silence internal revert This prepares for upcoming revert changes.

tests: fixup issue markers to make check-commit happy

incoming: don't request heads that already are common Pull would send a getbundle command where common heads were sent both as common and head, even though there is no reason to request a common head. The request was thus twice as big as necessary and more likely to hit HTTP header size limits. Instead, don't request heads that already are common. This is fixed in bundlerepo.getremotechanges . It could perhaps also have been fixed in discovery.findcommonincoming but that would have a bigger impact.

tests: improve test coverage for discovery and actual parameters for pulling