requirements: remove the `localrepo.supportedformat` attribute It is not longer used anywhere. Differential Revision: https://phab.mercurial-scm.org/D12035

requirements: sort _basesupported This will make the next changeset clearer. Differential Revision: https://phab.mercurial-scm.org/D12034

requirements: move the comment about manifestv2 in the module This is about requirements, so lets put it into the requirements module. We are about to remove code it was previously attached too. Differential Revision: https://phab.mercurial-scm.org/D12033

stream-clone: add a explicit set list requirements relevant to stream clone This set explicitly lists all the requirements that "stream clone" will preserve. Any other one will not be preserved. The role of listing the relevant one was previously filled by `repo.supportedformat`, but it seems clearer to use that such global and explicit set. The `repo.supportedformat` attribute will be cleaned up in a later changeset The true meaning of `repo.supportedformat` vs `repo._basesupported` was lost over time so, the content is currently bad. For example, `dirstate-v2` is currently considered relevant to the stream clone, or internal phase is missing. We kept the same content in this changeset and we will fix them later. Differential Revision: https://phab.mercurial-scm.org/D12032

stream-clone: filter possible missing requirements using all supported one 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

requirements: move "bookmark in store" requirements in the right module There seems to be no reasons to not have it with the others. Differential Revision: https://phab.mercurial-scm.org/D12030

stream-clone: add a explicit test for format change during stream clone 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

stream-clone: factor computation of requirement of a stream clone 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

stream-clone: factor computation of new clone requirement out 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

stream-clone: drop some outdated lines in test-stream-bundle-v2.t 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

relnotes: add note about changed labels texts Differential Revision: https://phab.mercurial-scm.org/D12085

graft: attempt to make merge labels more helpful Differential Revision: https://phab.mercurial-scm.org/D12025

shelve: attempt to make merge labels more helpful Differential Revision: https://phab.mercurial-scm.org/D12024

histedit: attempt to make merge labels more helpful Differential Revision: https://phab.mercurial-scm.org/D12023

update: set custom conflict label for base commit Differential Revision: https://phab.mercurial-scm.org/D12022

merge: set custom conflict label for base commit Differential Revision: https://phab.mercurial-scm.org/D12021

rebase: set custom conflict label for base commit Differential Revision: https://phab.mercurial-scm.org/D12020

simplemerge: take over formatting of label from `filemerge` 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

filemerge: pass `simplemerge.MergeInput` to tool functions Differential Revision: https://phab.mercurial-scm.org/D12018

filemerge: work with `simplemerge.MergeInput` in `filemerge()` 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

filemerge: always define a "base" label It simplifies the code and improves the conflict markers to always have the "base" label defined. Differential Revision: https://phab.mercurial-scm.org/D12016

filemerge: set default labels a little earlier 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

helptext: add missing newline to Rust helptext This makes it so the list renders properly. Differential Revision: https://phab.mercurial-scm.org/D12007

unamend: error out when running on merge commit It's better to error out than to produce a bad commit. We do that same in `hg uncommit`. I haven't looked into how much work it is to make them work instead. Differential Revision: https://phab.mercurial-scm.org/D12087