- Dec 23, 2020
-
-
Pierre-Yves David authored
Having explicit method with clear semantic help to clarify the code and prepare an update to the underlying documentation without too much disruption. Differential Revision: https://phab.mercurial-scm.org/D9643
-
Pierre-Yves David authored
The argument where not passed in the right other. This is not caught by the test (yet) because it is a sub case of a special case. Am I adding this to my list of things to test. Using test directly in Rust would be appropriate here. However we don't have the ability to test this code that way yet, and I am focussing on other part of that work right now. Differential Revision: https://phab.mercurial-scm.org/D9657
-
- Dec 21, 2020
-
-
Pierre-Yves David authored
Same rational as the previous changesets. CopySource is a clear descriptive name that does not depends on an implementation details that we are about to the change. Differential Revision: https://phab.mercurial-scm.org/D9642
-
- Dec 15, 2020
-
-
Pierre-Yves David authored
We are looking into moving away from TimeStampedPathCopy (that use is_ancestors call to detect overwrite) in favor of an approach that does not requires is_ancestors calls. Yet we will still need an internal representation that differs from the returned result. So we call it "InternalPathCopies" which is generic but clear. Differential Revision: https://phab.mercurial-scm.org/D9641
-
- Dec 12, 2020
-
-
Pierre-Yves David authored
We now detect and record when a merge case required special logic (eg: thing that append during the merge, ambiguity leading to picking p1 data, etc) and we explicitly mark the result as superseding the previous data. This fixes the family of test we previously added. Differential Revision: https://phab.mercurial-scm.org/D9613
-
- Dec 14, 2020
-
-
Pierre-Yves David authored
To properly handle the newly tested case (chaining of merges) we will need to detect more accurately when an actualy merging of the copy information (and superseed the two existing data). Before starting to do so, we need to reorganise the values comparison to introduce different conditional branches when such actual merging is needed/detected. To avoid mixing too many change in this complicated code, we do the reorganisation before adding the "overwrite detection" logic in the next changesets. Differential Revision: https://phab.mercurial-scm.org/D9612
-
Pierre-Yves David authored
Right now, the copy tracing logic take the right decision for merges, but it does not keep track of the right information about these decision and can fall into later traps. We start with highlighting this possibility by adding new tests, and we will fix them later. Check the inline test documentation for details. Differential Revision: https://phab.mercurial-scm.org/D9611
-
Pierre-Yves David authored
Right now, the copy tracing logic take the right decision for merges, but it does not keep track of the right information about these decision and can fall into later traps. We start with highlighting this possibility by adding new tests, and we will fix them later. Check the inline test documentation for details. Differential Revision: https://phab.mercurial-scm.org/D9610
-
- Feb 16, 2021
-
-
Pierre-Yves David authored
Right now, the copy tracing logic take the right decision for merges, but it does not keep track of the right information about these decision and can fall into later traps. We start with highlighting this possibility by adding new tests, and we will fix them later. Check the inline test documentation for details. Differential Revision: https://phab.mercurial-scm.org/D9609
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
This will make its role clearer.
-
Pierre-Yves David authored
Right now, everything mostly says "simple merge", we want to use something a bit more descriptive. Before doing any changes, we do most of the churn. This helps the next sets of changesets to be clearer.
-
- Feb 15, 2021
-
-
Pierre-Yves David authored
For main case (using filelog or sidedata), this lead to the following hash change. Changesets: - 01c2f5eabdc4ce2bdee42b5f86311955e6c8f573 → 319179230cc87769ab3a861ebffe7a534ebb3d85 - 01c2f5eabdc4 → 319179230cc8 - c72365ee036fca4fb27fd745459bfb6ea1ac6993 → 6cbc9c2b7b391dd738603173717c601648d3735f - c72365ee036f → 6cbc9c2b7b39 File revision for `f`: - 0dd616bc7ab1a111921d95d76f69cda5c2ac539c → cedeacc5bf5d9b9be4d7f8394d33a5349bb29c6e - 0dd616bc7ab1 → cedeacc5bf5d - eb806e34ef6be4c264effd5933d31004ad15a793 → ffb76cd765422a18759a335d8a81fa2bd455be6b - eb806e34ef6b → ffb76cd76542 - 6da5a2eecb9c833f830b67a4972366d49a9a142c → 08d1ff5926fbd0285cdeb044cbe8ab651687e86a - 6da5a2eecb9c → 08d1ff5926fb File revision for `d`: - 7bded9d9da1f7bf9bf7cbfb24fe1e6ccf68ec440 → ba177bbb45ea930ee48469a55d40224537bd57a9 For the "extra in changeset" case we get the following change for file `d`: - 68d5bca9df0577b6bc2ea30ca724e13ead60da81 → b894de5c94aadcb4894ea7c358389819c27fbcce - 68d5bca9df05 → b894de5c94aa - b80de5d138758541c5f05265ad144ab9fa86d1db → 56647659eff080e06e45c18ea9e848836dadea71 - b80de5d13875 → 56647659eff0
-
- Dec 10, 2020
-
-
Pierre-Yves David authored
This effectively back out changeset deeb215be337. Changeset deeb215be337 does not really include a justification for its change and make mes uncomfortable. I have been thinking about it and they are two options: - either having empty/full files does not make a difference, and deeb215be337 is a gratuitous changes. - either having empty/full files do make a difference and deeb215be337 silently change the test coverage. In such situation if we want the "not empty" case to be tested, we should add new cases to cover them In practice, we know that the "file content did not change, but merge still need to create a new filenode" case exists (for example if merging result in similar content but both parent of the file need to be recorded), and that such case are easy to miss/mess-up in the tests. Having all the file using the same (empty) content was done on purpose to increase the coverage of such corner case. As a result I am reinstalling the previous test situation. To increase the coverage of some case involving content-merge in test-copies-chain-merge.t, we will add a new, dedicated, cases later in this series, once various cleanup and test improvement have been set in place. This changeset starts with reinstalling the previous situation as (1) it is more fragile, so I am more confided getting it back in the initial situation, (2) I have specific test further down the line that are base on these one. The next changeset will slightly alter the test to use non-empty files for these tests (with identical content). It should help to make the initial intent "merge file with identical content" clearer. I am still using a two steps (backout, then change content) approach to facilitate careful validation of the output change. Doing so has a large impact on the output of the "copy info in changeset extra" variant added in 5e72827dae1e (2 changesets after deeb215be337). It seems to highlight various breakage when merge without content change are involved, this is a good example of why we want to explicitly test theses cases. Because the different -do- matters a lot. Fixing the "copy info in changeset extra" is not a priority here. Because (1) this changeset does not break anything, it only highlight that they were always broken. (2) the only people using "copy info in changeset extra" do not have merge. Differential Revision: https://phab.mercurial-scm.org/D9587
-
- Feb 04, 2021
-
-
Kyle Lippincott authored
I spent at least an hour, probably closer to 1.5, trying to figure out what this was complaining about. Hopefully anyone else in my position will see this note and not waste the time. Differential Revision: https://phab.mercurial-scm.org/D9953
-
- Jan 27, 2021
-
-
Jörg Sonnenberger authored
The only consumer can handle revision lists fine. Avoid materializing a range if there are no duplicates as optimization. Differential Revision: https://phab.mercurial-scm.org/D9884
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9883
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9882
-
- Jan 26, 2021
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9881
-
Jörg Sonnenberger authored
The node is passed as argument already, so returning it is quite pointless. The revision number on the other is useful as it decouples the caller from the revlog internals. Differential Revision: https://phab.mercurial-scm.org/D9880
-
- Feb 08, 2021
-
-
Simon Sapin authored
Only with one argument and no flag. This is mostly for testing. Differential Revision: https://phab.mercurial-scm.org/D9972
-
Simon Sapin authored
Differential Revision: https://phab.mercurial-scm.org/D9971
-
Simon Sapin authored
Differential Revision: https://phab.mercurial-scm.org/D9970
-
Simon Sapin authored
This removes some repetition, and will avoid additional repetition in the next commit. Differential Revision: https://phab.mercurial-scm.org/D9969
-
Simon Sapin authored
Differential Revision: https://phab.mercurial-scm.org/D9968
-
Simon Sapin authored
The `Command` trait was not used in any generic context, and the struct where nothing more than holders for values parsed from CLI arguments to be available to a `run` method. Differential Revision: https://phab.mercurial-scm.org/D9967
-
Simon Sapin authored
This is similar to `std::fmt::Display`, but for arbitrary bytes instead of Unicode. Writing to an abstract output stream helps avoid allocating intermediate `Vec<u8>` buffers. Differential Revision: https://phab.mercurial-scm.org/D9966
-
- Feb 04, 2021
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D9958
-
Martin von Zweigbergk authored
We'll want to reuse the logic that `hg diff --change` with `diff.merge` uses. At least `hg log -p` should reuse it. This patch therefore extracts that code to a function. Differential Revision: https://phab.mercurial-scm.org/D9957
-
Martin von Zweigbergk authored
I can't think of any reason you'd want to enable the merge diff on a run-to-run basis; you'd probably either always or never want it set (though I can't see why you'd never want it set). If you have it set, you'll probably also want the same output in `hg log -p` output. Having a single config option for the feature makes sense. Differential Revision: https://phab.mercurial-scm.org/D9956
-
- Dec 24, 2020
-
-
Matt Harbison authored
The TortoiseHg repo has typically not had a newly applied tag accessible by name for recent releases, for unknown reasons. Deleting and rebuilding the tag cache doesn't fix it, though deleting the cache and running `hg log -r $new_tag` does. Eventually the situation does sort itself out for new clones from the server. In an effort to figure out what the issue is, Pierre-Yves David suggested listing these entries in the debug output more specifically. This isn't complete yet- the second test change that says "missing" is more like "invalid", since it was truncated. The problem there is the code that reads the raw array truncates any partial records and then fills it with 0xFF, which signifies that it is missing. As a side note, that means the check for the length when validating an existing entry never fails. Differential Revision: https://phab.mercurial-scm.org/D9811
-
- Feb 12, 2021
-
-
Martin von Zweigbergk authored
-
- Feb 10, 2021
-
-
Pierre-Yves David authored
That setting restore the behavior pre-5.6. The current HGPLAIN value is simply passed to the hooks. This allow user who needs it to fully mitigate the behavior change introduced in Mercurial 5.7 by restoring the older behavior. Differential Revision: https://phab.mercurial-scm.org/D9982
-