check-commit: check for double-addition of blank lines Previously, we were only checking for a blank line being added next to an existing one. Now we also check for two being added at the same time.

check-commit: scan for multiple instances of error patterns

merge: add file ancestor linknode to mergestate During a merge, each file has a current commitnode+filenode, an other commitnode+filenode, and an ancestor commitnode+filenode. The ancestor commitnode is not stored though, and we rely on the ability for the filectx() to look up the commitnode by using the filenode's linkrev. In alternative backends (like remotefilelog), linkrevs may have restriction that prevent arbitrary linkrev look up given a filenode. This patch accounts for that by storing the ancestor commitnode in the merge state so that it is available later at resolve time. This results in some test changes because the ancestor commitnode we're using at resolve time changes slightly. Before, we used the linkrev commit, which is the earliest commit that introduced that particular filenode (which may not be the latest common ancestor of the commits being merged). Now we use the latest common ancestor of the merged commits as the commitnode. This is fine though, because that commit contains the same filenode as the linkrev'd commit.

merge: add debugmergestate support for _stateextras Now that we can store extras for each file, we need to have support for showing it in debugmergestate (the tests depend on this).

merge: add state extras merge state data In future commits we will want to store more data related to each file in the merge state. This patch adds an optional record for storing a dictionary of extras for each file.

revset: use manifest.matches in _follow revset The old _follow revset iterated over every file in the commit and checked if it matched. For repos with large manifests, this could take 500ms. By switching to use manifest.matches() we can take advantage of the fastpaths built in to manifest.py that allows iterating over only the files in the matcher when it's a simple matcher. This brings the time spent down from 500ms to 0ms during simple operations like 'hg log -f file.txt'.