configitems: get default values from the central registry when available We do not have any registered config yet, but we are now ready to use them. For now we ignore this feature for config access with "alternates". On the long run, we expect alternates to be handled as "aliases" by the config item themself.

configitems: introduce a central registry for config option We now have the appropriate infrastructure to register config items. Usage will added in the next changeset.

configitems: add a basic class to hold config item information The goal of this class is allow explicit declaration for the available config option. This class will hold the data for one specific config item. To keep it simple we start centralizing the handling of the default config value. In the future we can expect more data to be carried on this class. For example: - documentation, - status (experimental, advanced, normal, deprecated), - aliases, - expected type, - etc...

run-tests: fix -i when "#testcases" is used in .t test The "#testcases" feature introduced by 7340465bd788 has issues with "-i" because "-i" uses "test.name.endswith('.t')" to test if a test is .t or not. test.name could now be something like "test-foo.t (caseA)" so the above endswith test is no longer valid. This patch changes the test to use "self.path" which won't have the issue.

run-tests: update .t reference output after reading the test The .t file is both test input and reference output. They should always match. However we have different code paths to read reference output (Test.__init__ -> Test.readrefout) and test input (TTest._run) so they might be inconsistent if somethings change the file between those two functions. This patch assigns "lines" read by "_run" back to "_refout" if "_refout" is not None (with --debug, see Test.readrefout) so reference output and test input will always match.

run-tests: do not prompt changes (-i) if a race condition is detected The race condition is like: 1. run-tests.py reads test-a.t as reference output, content A 2. run-tests.py runs the test (which could be content B, another race condition fixed by the next patch, but assume it's content A here) 3. something changes test-a.t to content C 4. run-tests.py compares test output (content D) with content A 5. with "-i", run-tests.py prompts diff(A, D), while the file has content C instead of A at this time This patch detects the above case and tell the user to rerun the test if they want to apply test changes.

patch: rewrite reversehunks (issue5337) The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw recordhunk without crecord selection information, therefore "revert -i" cannot revert individual lines, aka. issue5337. The patch rewrites related logic to return the right reverse hunk for revert. Namely, 1. "fromline" and "toline" are correctly swapped [1] 2. crecord.uihunk generates a correct reverse hunk [2] Besides, reversehunks(hunks) will no longer modify its input "hunks", which is more expected. [1]: To explain why "fromline" and "toline" need to be swapped, take the following example: $ cat > a <<EOF > 1 > 2 > 3 > 4 > EOF $ cat > b <<EOF > 2 > 3 > 5 > EOF $ diff a b 1d0 <---- "1" is "fromline" and "0" is "toline" < 1 and they are swapped if diff from the reversed direction 4c3 | < 4 | --- | > 5 | | $ diff b a | 0a1 <---------+ > 1 3c4 <---- also "4c3" gets swapped to "3c4" < 5 --- > 4 [2]: This is a bit tricky. For example, given a file which is empty in working parent but has 3 lines in working copy, and the user selection: select hunk to discard [x] +1 [ ] +2 [x] +3 The user intent is to drop "1" and "3" in working copy but keep "2", so the reverse patch would be something like: -1 2 (2 is a "context line") -3 We cannot just take all selected lines and swap "-" and "+", which will be: -1 -3 That patch won't apply because of "2". So the correct way is to insert "2" as a "context line" by inserting it first then deleting it: -2 +2 Therefore, the correct revert patch is: -1 -2 +2 -3 It could be reordered to look more like a common diff hunk: -1 -2 -3 +2 Note: It's possible to return multiple hunks so there won't be lines like "-2", "+2". But the current implementation is much simpler. For deletions, like the working parent has "1\n2\n3\n" and it was changed to empty in working copy: select hunk to discard [x] -1 [ ] -2 [x] -3 The user intent is to drop the deletion of 1 and 3 (in other words, keep those lines), but still delete "2". The reverse patch is meant to be applied to working copy which is empty. So the patch would be: +1 +3 That is to say, there is no need to special handle the unselected "2" like the above insertion case.