rebase: add test for in-memory merge conflicts

rebase: call _dorebase() properly This fixes a regression from e9e742bd0501 where we failed to pass all necessary arguments to _dorebase(). Differential Revision: https://phab.mercurial-scm.org/D4302

context: make sure file is not deleted while checking path conflicts If a file is deleted and a directory of same name is created in the same commit, IMM thinks of that as a file conflict, however the file is deleted and hence the directory can be created. The test change demonstrate the fix. Differential Revision: https://phab.mercurial-scm.org/D4300

tests: demonstrate that IMM needs to be smarter with path conflicts When we try to rebase a commit which deletes an existing file and make a directory of the same name, rebase with IMM aborts. It should work fine just like the without IMM case. Differential Revision: https://phab.mercurial-scm.org/D4299

tests: don't create new repo inside existing repo in test-rebase-inmemory.t Differential Revision: https://phab.mercurial-scm.org/D4298

tests: remove test-py3-commands.t This was a smoke test for early in the Python 3 porting effort, before anything actually worked. Now that we've got over half the testsuite passing, this test has outlived its utility. Differential Revision: https://phab.mercurial-scm.org/D4288

tests: update test-check-py3-compat.t output in the py3exe branch This hasn't been maintained in a while, it looks like. Differential Revision: https://phab.mercurial-scm.org/D4289

overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960) If there was a metadata-only mutation, such as +x or -x on a file, we would create a cache entry with None for data, and this would cause problems later on when some code tried to run fctx.data() or similar, and was expecting a string. My original fix for this involved passing data=self._wrappedctx[path].data() in setflags(), but this version seems slightly better - this way, if we ever call write() and then call setflags(), we don't destroy the data that we wrote that's in the cache. I haven't verified that other fields aren't destroyed, such as date or flags :) Differential Revision: https://phab.mercurial-scm.org/D4287

filemerge: show actual capabilities of internal merge tools This information is useful to know which internal merge tools can be applied safely on binary files and/or symlinks.

filemerge: add config knob to check capabilities of internal merge tools For historical reason, Mercurial assumes capabilities of internal merge tools as below while examining rules to decide merge tool, regardless of actual capabilities of them. =============== ====== ======== specified via binary symlinks =============== ====== ======== --tool o o HGMERGE o o merge-patterns o (*) x (*) ui.merge x (*) x (*) =============== ====== ======== This causes: - unintentional internal merge tool is chosen for binary files via merge-patterns section of configuration file - explicit configuration of internal merge tool for symlinks is ignored unintentionally But on the other hand, simple "check capability strictly" might break backward compatibility (e.g. existing merge automations), because it changes the result of merge tool selection. Therefore, this patch adds config knob "merge.strict-capability-check" to control whether capabilities of internal merge tools should be checked strictly or not. If this configuration is true, capabilities of internal merge tools are checked strictly in (*) cases above.

filemerge: show warning if chosen tool has no binary files capability While matching patterns in "merge-patterns" configuration, Mercurial silently assumes that all merge tools have binary files capability. This implementation comes from 5af5f0f9d724 (or Mercurial 1.0). At failure of merging binary files with incorrect internal merge tool, there is no hint about this silent ignorance of binary files capability. This patch shows warning message, if chosen internal merge tool has no binary files capability. This will help users to investigate why a binary file isn't merged as expected.

filemerge: add the function to examine a capability of a internal tool For "symlink" and "binary" capabilities, _toolbool() can not examine these of internal merge tools strictly, because it examines only configurations in "merge-tools" section. Users can configure them explicitly as below for example, but this is not ordinary usage and not convenient: [merge-tools] :other.symlink = true :other.binary = true This patch adds hascapability() internal function, which can examine actual capabilities of a internal merge tool strictly. At this patch, hascapability() is still used with "strict=False". Subsequent patches use it with "strict=True".

filemerge: set actual capabilities of internal merge tools This information is used to detect actual capabilities of internal merge tools by subsequent patches. For convenience, this patch assumes that merge tools typed as "nomerge" have both binary files and symlinks capabilities.

help: describe more detail about capabilities while deciding merge tool "hg help merge-tools" describes as below: (internal merge tools) will by default not handle symlinks or binary files. But in some cases, Mercurial assumes that internal merge tools have one or both of these capabilities. "hg help merge-tools" also describes as below, for matching patterns in merge-patterns configuration section. But this is not sufficient. Here, binary capabilities of the merge tool are not considered. This patch describes more detail about capabilities while deciding merge tool.