copies: filter out copies when target is not in destination manifest When chaining a series of commits that copied a file with a series that removed the destination file, we would still include the copy in the result. Similar to the previous patch, I have checked that `hg status --copies` is not affected by this bug, but I wouldn't be surprised if some commands are. Differential Revision: https://phab.mercurial-scm.org/D5989

copies: make _backwardrenames() filter out copies by destination As shown by the test case, _backwardrenames() doesn't filter by the matcher. It doesn't show up in `hg status --copies` because that only prints files changed between the two commits. I wouldn't be surprised if some other command that replies on pathcopies() was broken before this patch, but I haven't bothered to check other commands. Differential Revision: https://phab.mercurial-scm.org/D5988

copies: respect narrowmatcher in "parent -> working dir" case I don't know when this case happens and we don't seem to have tests for it, but let's fix it anyway since I happened to notice it. Differential Revision: https://phab.mercurial-scm.org/D5987

tests: add tests of pathcopies() I'm working on support for storing copy metadata in the changeset instead of in the filelog. When storing it in the changeset, it will obviously be efficient to get the copy metadata for all files in a single changeset, but it will be more expensive to get the copy metadata all revisions of a single file. Some algorithms will then need to be optimized differently. The first method I'm going to rewrite is pathcopies(). This commit adds many tests for pathcopies(), so we can run the tests with both old and new versions of the code, as well as with metadata stored in filelog or in changeset (later). They use the debugpathcopies command I recently added (with no tests when it was added). They show a few bugs and few cases of slightly weird behavior. I'll fix the bugs in the next few commits. Differential Revision: https://phab.mercurial-scm.org/D5986

uncommit: add config option to keep commit by default We have a Google-internal extension that keeps track of "review units" (like Phabricator reviews, or Gerrit's Change-Id). This information is stored outside of the commit. It is updated with rewrites. Every now and then we get reports from users who are confused because `hg uncommit` lost track of their review. Keeping the empty commit by default would reduce this confusion. It may also cause confusion about the empty commit. This patch adds a config option that lets us easily test both behaviors on our users. Differential Revision: https://phab.mercurial-scm.org/D5970

debugpathcopies: sort output so it's deterministic Differential Revision: https://phab.mercurial-scm.org/D5983

subrepo: use root-repo-relative path from `hg files` with ui.relative-paths=no The fix is to pass in a "subuipathfn" as we do everywhere else. Differential Revision: https://phab.mercurial-scm.org/D5978

subrepo: demonstrate broken `hg files` with ui.relative-paths=no Differential Revision: https://phab.mercurial-scm.org/D5977

py3: whitelist 5 new passing tests caught by buildbot Thanks to indygreg and durin42 recent patches. Differential Revision: https://phab.mercurial-scm.org/D5979

uncommit: inform user if the commit is empty after uncommit Differential Revision: https://phab.mercurial-scm.org/D5969

test: stabilize test-run-tests.t output We have reached a point where the duration in JSON reports of `test-run-tests.t` were greater or equal than 10 seconds, which doesn't match anymore the regex. For example here: https://ci.octobus.net/blue/organizations/jenkins/MercurialPy2/detail/MercurialPy2/276/pipeline ``` "diff": "", ? (re) - "end": "\s*[\d\.]{4,5}", ? (re) + "end": "10.040", "result": "skip", ? (re) ``` Instead of accepting more characters, I changed the regex to accept any number of digits before the `.` then 3 or 4 digits after. This way the regex is more precise (only one `.` is authorized and we can ensure that the precision doesn't change). Differential Revision: https://phab.mercurial-scm.org/D5966

test: stabilize test-remotefilelog-bgprefetch.t flaky output When running the test suite with multiple processes, we often get flaky outputs, like here: https://ci.octobus.net/job/MercurialPy2/274/console ``` - $TESTTMP/hgcache/master/packs/8f1443d44e57fec96f72fb2412e01d2818767ef2.histidx - $TESTTMP/hgcache/master/packs/8f1443d44e57fec96f72fb2412e01d2818767ef2.histpack - $TESTTMP/hgcache/master/packs/f4d50848e0b465e9bfd2875f213044c06cfd7407.dataidx - $TESTTMP/hgcache/master/packs/f4d50848e0b465e9bfd2875f213044c06cfd7407.datapack + $TESTTMP/hgcache/master/11/f6ad8ec52a2984abaafd7c3b516503785c2072/1406e74118627694268417491f018a4a883152f0 + $TESTTMP/hgcache/master/11/f6ad8ec52a2984abaafd7c3b516503785c2072/ef95c5376f34698742fe34f315fd82136f8f68c0 + $TESTTMP/hgcache/master/39/5df8f7c51f007019cb30201c49e884b46b92fa/69a1b67522704ec122181c0890bd16e9d3e7516a + $TESTTMP/hgcache/master/95/cb0bfd2977c761298d9624e4b4d4c72a39974a/076f5e2225b3ff0400b98c92aa6cdf403ee24cca + $TESTTMP/hgcache/master/af/f024fe4ab0fece4091de044c58c9ae4233383a/bb6ccd5dceaa5e9dc220e0dad65e051b94f69a2c ``` Add some sleeps after `debugwaitonrepack` calls as it seems it needs some extra time to cleanup. Differential Revision: https://phab.mercurial-scm.org/D5960

merge with stable

color: change color of grep.rev label (BC) GNU grep uses green for line numbers as we do, but I sometimes get a bit confused when I do `hg grep --diff -n` and get both line numbers and revisions and don't know which one is which. A different colour can help.

color: give colours to the grep.inserted and grep.deleted labels I find the "bold" makes it stand out a bit more when the green is next to the line number. Note that these labels are applied before the grep.change label, which is now disabled. To get the old colour, users can restore [color] grep.change = green dim to their hgrc.

grep: give different labels to + and - symbols I find it more useful to give different colours to plus and minus, but it's difficult to do so if the default output uses the same label for both. The following augments the names of columns with some extra labels, akin to the diff.inserted and diff.deleted labels for the diff command. This is done by adding an extra label field to the columns tuples.

tests: bulk changes to avoid whitespace errors of check-code.py This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts. This revision avoids "whitespace" errors of check-code.py below: - missing whitespace after "," - missing whitespace in expression - no whitespace around "=" for named parameters - wrong whitespace around "="

tests: replace "naked except clause" to avoid check-code.py error This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts.

tests: bulk changes to avoid "omit superfluous pass" check-code.py error This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts.

tests: replace imported module to avoid check-code.py error This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts.

tests: bulk change to avoid "unneeded trailing ',' ..." error of check-code.py This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts. "trailing ','" at the end of command option list in the code fragment of test-bundle2-format.t is still left as it is, in order to follow the style of command definitions in Mercurial core.

tests: define class in modern style to avoid check-code.py error This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts.

tests: use NO_CHECK_EOF as heredoc limit mark to omit checking code fragments This is a part of preparation to apply checking with check-code.py on code fragments embedded in *.t test scripts. "primes.py" embedded in test-highlight.t causes an error of check-commit.py below: don't use .next(), use next(...) But changing embedded primes.py is painful, because it is committed in test script, and affects hash IDs. On the other hand, primes.py itself is never executed in test script. Therefore, this patch uses NO_CHECK_EOF as heredoc limit mark in order to omit any checking on this code fragments.

tests: conditionalize msys path mangling in test-bundle.t This broke in 252cc56c9ff6 when the variables were printed one per line. The only reason I can think of is that MSYS knew the former string couldn't be a list of paths, but thinks this form is.

tests: glob over quoting differences in test-blackbox.t for Windows

chistedit: ensure a locale is set My paternal surname was showing incorrectly without this fix.

templatekw: make negrev return empty for wdir() and nullrev I considered just returning the same output that {rev} returns here, but {rev} also returns essentially gibberish: either an INT_MAX-kind of variable for wdir() or -1 for null. Since these are numbers that are intended to be used for calculations, and since the numbers for wdir() and -1 are not really very helpful for calculation (and worse, when used as a revision number -1 is equal to unhidden tip), I figured the most reasonable thing to do here is to just return nothing for negrev. This could potentially break scripts that are expecting to parse a nonempty integer out of a {negrev}, but that seems like a very remote concern at this juncture.

test-sqlitestore: run sqlite3 with no init file These tests were failing for me because I have a ~/.sqliterc that alters the default output. Tests should ignore any init file.

tests: add a missing abort exit code on Windows in test-audit-subrepo.t

subrepo: add test for Windows relative-ish path with drive letter Matt Harbison pointed out that Windows had some weird path syntax. Fortunately it's rejected appropriately by pathauditor, so we're safe. Let's test the behavior as we have a special handling for Windows drive letters. This patch includes a basic example. Maybe we'll need to extend the test case further, but writing such tests on Linux isn't easy.