- Jan 24, 2022
-
-
Pierre-Yves David authored
The `supportedformat` requirements is missing some important requirements and it seems better to filter out with all requirements we know, not just an "arbitrary" subset. This is especially relevant as we about to phase out the `supportedformat` class attribute. (a backport of this change to stable should be sent soon). Differential Revision: https://phab.mercurial-scm.org/D12031
-
- Jan 17, 2022
-
-
Pierre-Yves David authored
There seems to be no reasons to not have it with the others. Differential Revision: https://phab.mercurial-scm.org/D12030
-
Pierre-Yves David authored
They are different kind of requirements, the one which impact the data storage and are relevant to the files being streamed and the one which does not. For example some requirements are only relevant to the working copy, like sparse, or dirstate-v2. Since they are irrelevant to the content being streamed, they do not prevent the receiving side to use streaming clone and mercurial skip adverting them over the wire and, ideally, within the bundle. In addition, this let the client decide to use whichever format it desire for the part that does not affect the store itself. So the configuration related to these format are used as normal when doing a streaming clone. In practice, the feature was not really tested and is badly broken with bundle-2, since the requirements are not filtered out from the stream bundle. So we start with adding simple tests as a good base before the fix and adjust the feature. Differential Revision: https://phab.mercurial-scm.org/D12029
-
- Jan 14, 2022
-
-
Pierre-Yves David authored
This gather code duplicated in multiple place and will make it easier to modify it safely in the future. Differential Revision: https://phab.mercurial-scm.org/D12028
-
Pierre-Yves David authored
This gather code duplicated in multiple place and will make it easier to modify it safely in the future. Differential Revision: https://phab.mercurial-scm.org/D12027
-
- Jan 17, 2022
-
-
Pierre-Yves David authored
These line refer to a "dirstate-v2" variant that is no longer in use. The associated line drifted out of sync with reality. Differential Revision: https://phab.mercurial-scm.org/D12026
-
- Jan 24, 2022
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12085
-
- Jan 21, 2022
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12025
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12024
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12023
-
- Jan 18, 2022
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12022
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12021
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12020
-
- Jan 20, 2022
-
-
Martin von Zweigbergk authored
The padding we do of conflict labels depends on which conflict marker style is used. For two-way conflict markers (the default), the length of the base label shouldn't matter. It does before this patch, however. This patch moves the formatting from `filemerge` to `simplemerge`. The latter knows which conflict marker style to use, so it can easily decide about the padding. This change will allow us to use more descriptive "base" labels without causing illogical padding in 2-way markers. I'll do that next. One wrinkle is that we pass the same labels to external merge tools. I decided to change that in this patch to be simpler: no padding, and no ellipsis to fit within 80 columns. My reasoning is that the typical external, 3-or-4-panel merge tool doesn't show the labels on top of each others, so the padding doesn't make sense there. The ellipsis is probably not necessary because the external tools probably have their own way of dealing with long labels. Also, we limit them to "80 - 8" to fit the "<<<<<<< " before, which is almost definitely not what an external tool would put there. Differential Revision: https://phab.mercurial-scm.org/D12019
-
- Jan 21, 2022
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12018
-
- Jan 20, 2022
-
-
Martin von Zweigbergk authored
We currently pass around pairs of file context objects and labels between functions in the `filemerge` module. I plan to pass around `simplemerge.MergeInput` instead. This patch prepares for that by using the type internally in `filemerge.filemerge()`. Differential Revision: https://phab.mercurial-scm.org/D12017
-
Martin von Zweigbergk authored
It simplifies the code and improves the conflict markers to always have the "base" label defined. Differential Revision: https://phab.mercurial-scm.org/D12016
-
Martin von Zweigbergk authored
By setting the default labels a little earlier, we can rely on them always being set, as far as I can tell. It may actually even be fine to rely on that even if we don't set them earlier, but it makes more sense to me to do it. Differential Revision: https://phab.mercurial-scm.org/D12015
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D12014
-
Martin von Zweigbergk authored
The labels we put in conflict markers are formatted so the part before the ':' (typically says things like "local") is padded so the ':' is aligned among the labels. That means that if you specify a long label for "base" but the conflict marker style is "merge" (i.e. 2-way), the other two will have unwanted padding. We often don't specify a label for the base, so we don't notice the problem (and it may very well be that it didn't exist before my D11972). I think the best fix is to pass the labels along with the context objects, so the low-level code that switches on the marker style to use (i.e. `simplemerge`) can do the formatting. This patch starts doing that by passing a fully-formatted label to `simplemerge`. A coming patch will move the formatting to `simplemerge`. Differential Revision: https://phab.mercurial-scm.org/D12013
-
Martin von Zweigbergk authored
We always pass labels, and it's always a non-empty list, so we can simplify a bit. Differential Revision: https://phab.mercurial-scm.org/D12012
-
Martin von Zweigbergk authored
Looking at the statement just before, the string is clearly never empty (or otherwise falsy). Differential Revision: https://phab.mercurial-scm.org/D12011
-
- Jan 21, 2022
-
-
Martin von Zweigbergk authored
Our fake merge tool printed the arguments using `$1` etc. without quotes, which means that the shell collapsed repeated spaces within the argument. That resulted in tests that did not pick up changes to the number of spaces. Differential Revision: https://phab.mercurial-scm.org/D12010
-
- Jan 18, 2022
-
-
sliquister authored
AFAIK, year/month/day is not a format than anyone uses. It seems more sensible to me to use ISO 8601, as that's standard and unambiguously year-month-day. Compatibility-wise, I think it's acceptable to change the default format. It's most for human consumption. It's plausible that a few tools parse this format, but it has already changed in the past (for instance to add the current revision). Differential Revision: https://phab.mercurial-scm.org/D12006
-
sliquister authored
The current second granularity is often not specific enough to determine whether an hg command is happening before or after some other event. Given that starting a process takes on the order of 1ms (well, for native processes. It's quite a bit more for python processes), microseconds seems like unnecessary noise. This also lines up behavior with the rust version, where we already switched to millisecond precision. Differential Revision: https://phab.mercurial-scm.org/D12005
-
sliquister authored
Differential Revision: https://phab.mercurial-scm.org/D12004
-
Raphaël Gomès authored
-
- Dec 30, 2021
-
-
Dan Villiom Podlaski Christiansen authored
I'm not all _that_ versed in Rust, but I think the root cause is that some constants are u16 rather than u32 on Darwin. I checked that the code still compiles on the latest Ubuntu. Differential Revision: https://phab.mercurial-scm.org/D11955
-
- Jan 17, 2022
-
-
Simon Sapin authored
OwningDirstateMap used to own a PyBytes, but was generalized to be more generic when it was moved from hg-cpython to hg-core. This fixes some comments that were still referencing PyBytes. Differential Revision: https://phab.mercurial-scm.org/D12003
-
- Jan 14, 2022
-
-
Martin von Zweigbergk authored
Returning `None` from `simplemerge()` means that the caller interprets it as "no merge was necessary (because two sides matched)". See 6217040b2780 and issue2680 for some background. However, `simplemerge()` shouldn't even get called in such scenarios, and returning `None` means that the file is not considered merged, even though the contents actually were. See the affected test cases. Differential Revision: https://phab.mercurial-scm.org/D11999
-
Martin von Zweigbergk authored
The only user was removed in f18830651811 (simplemerge: burn "minimal" feature to the ground, 2014-08-05). Differential Revision: https://phab.mercurial-scm.org/D11998
-
- Jan 12, 2022
-
-
Martin von Zweigbergk authored
`_minimize()` is weird in that it changes `a_lines` and `b_lines` but leaves `base_lines` unchanged, which means they'll be inconsistent. That was fine because the caller never used `base_lines`. With the recent refactorings of this code, we can now make this function cleaner by having it minimize a single conflict and not care about `base_lines`. This also makes the code simpler and makes the code for each `render_*()` function more similar. Differential Revision: https://phab.mercurial-scm.org/D11981
-
Martin von Zweigbergk authored
IMO, `Merge3Text` should be about merging text without knowing about conflict markers. "Conflict minimization" is about making conflict markers smaller, so it should be moved out. This patch does that. I'll refactor it next. Differential Revision: https://phab.mercurial-scm.org/D11980
-
Martin von Zweigbergk authored
`render_markers()` now always renders minimized 2-way markers, so let's simplify and rename it accordingly. Differential Revision: https://phab.mercurial-scm.org/D11979
-
Martin von Zweigbergk authored
The results in some duplicate, but the code is very straight-forward and I think it's worth it to have each conflict marker style in a separate function. Differential Revision: https://phab.mercurial-scm.org/D11978
-
- Jan 08, 2022
-
-
Martin von Zweigbergk authored
I want to remove knowledge of paths from the `simplemerge` core module. As part of that, let's move the default labels from the core module to the extension. Differential Revision: https://phab.mercurial-scm.org/D11977
-
Martin von Zweigbergk authored
The `:merge` and `:merge3` markers used the newline style detected from the base input. The `:mergediff` style always used LF as newline character. This patch teaches `:mergediff` to use the same detection as the others did. Differential Revision: https://phab.mercurial-scm.org/D11976
-
- Jan 12, 2022
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D11975
-
- Jan 08, 2022
-
-
Martin von Zweigbergk authored
IMO, the rendering of a conflict as text with merge markers should be separate from the code for resolving conflicts. The latter is what `Merge3Text` is mostly about already. Differential Revision: https://phab.mercurial-scm.org/D11974
-
Martin von Zweigbergk authored
We always consume all the lines and put them in a list anyway. By making the function not a generator, we can later make it return an additional value (to indicate if there were conflicts). Differential Revision: https://phab.mercurial-scm.org/D11973
-