rebase: use one dirstateguard for when using rebase.singletransaction This was previously landed as 2519994d25ca but backed out in b63351f6a2 because it broke hooks mid-rebase and caused conflict resolution data loss in the event of unexpected exceptions. This new version adds the behavior back but behind a config flag, since the performance improvement is notable in large repositories. The old commit message was: Recently we switched rebases to run the entire rebase inside a single transaction, which dramatically improved the speed of rebases in repos with large working copies. Let's also move the dirstate into a single dirstateguard to get the same benefits. This let's us avoid serializing the dirstate after each commit. In a large repo, rebasing 27 commits is sped up by about 20%. I believe the test changes are because us touching the dirstate gave the transaction something to actually rollback. (grafted from 9e3dc3a1638b9754b58a0cb26aaa75d868058109) (grafted from 7d38b41d2266d9a02a15c64229fae0da5738dcec) Differential Revision: https://phab.mercurial-scm.org/D135

README: make paragraphs before example code end with "::" for reST syntax After this patch, README as reST text can be rendered into HTML more appropriately. This is useful for hosting servers, which render README file as a part of index HTML of its directory (for example, Bitbucket).

commit: don't let failed commit with --addremove update dirstate (issue5645) Differential Revision: https://phab.mercurial-scm.org/D204

tests: demonstrate that failed "hg ci -A" updates dirstate (issue5645) Differential Revision: https://phab.mercurial-scm.org/D203

tests: fix test-flagprocessor.t flakiness The test for duplicate flag processors depended on the timestamps being set in the dirstate to work. If the time between the the previous failed commit (which would set the timestamp, due to bug 5645) and the attempted commit with the duplicate flag processors was small enough, it would fail. The failure was caused by a call to commands.status() early in the commit process. If the dirstate did not have the timestamp set, it would need to fetch the file content to compare with. Since two flag processors had been registered, it would attempted to base64 decode the contents twice, which would of course fail. This patch adds a "hg debugrebuilddirstate" to make it deterministic and also replaces the test case's "hg commit" by simply "hg status", since that will trigger reading of the contents and thereby use of the flag processors as noted above. Differential Revision: https://phab.mercurial-scm.org/D202

tests: clarify that duplicate flag processors is not an error The flag processors test for duplicate processors for a single flag was misleading because the file from the previous test case caused it to fail (making the "echo 'this should fail' > file" part irrelevant). Let's remove the leftover from the previous test case to make it clear that duplicate flag processors results only in a warning. Note that duplicate flag processors would have resulted in a failure (not just a warning) until ea1c2eb7abd3 (extensions: catch uisetup and extsetup failures and don't let them break hg, 2017-06-06). I remember expressing my concern about ending up with half-loaded extensions. It would be pretty unfortunate to have double-encoded revlog content enter a repo, so maybe we should reconsider? Differential Revision: https://phab.mercurial-scm.org/D201

tests: avoid unexpected result at invocation of *.py file on Windows Invocation of "diff tool.py" in test-extdiff.t tests whether shellquote() is applied on specified command as expected. But direct invocation of "*.py" file might cause unexpected result on Windows according to suffix binding. For example, starting IDE, showing dialog to choose program to be used, and so on. In such case, running test-extdiff.t is easily timed out. This patch uses intermediate *.bat file on Windows, to avoid such unexpected result. Naming that intermediate file as "diff tool.bat" is enough to test applying shellquote().

tests: use pdiff instead of diff for portability "diff" command might cause redundant message, "No differences encountered" on Solaris for example. But suppressing option like "-q" isn't portable, because POSIX specification doesn't define it. pdiff script was introduced by b59ef0c21405 to stabilize output of standard diff command on each platforms.

tests: make pdiff return appropriate exit code at comparison of files Before this patch, pdiff script returns 0, even if diff is detected. This issue doesn't cause failure of tests using it, if it is invoked via extdiff extension, because extdiff itself examines changes between specified revisions and decides exit code. BTW, this patch ignores recursive comparison case, because: - there is no portable way for current while-read based implementation to return 1 at detecting changes - it isn't yet needed to replace direct "diff -r" invocation by pdiff for portability

merge with stable