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