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

tests: demonstrate how `hg unamend` fails on merge commits When `hg unamend` is run on a merge commit, it seems that it loses the changes from the second parent. Differential Revision: https://phab.mercurial-scm.org/D12086

filemerge: remove unused arguments from `_merge()` Differential Revision: https://phab.mercurial-scm.org/D12014

simplemerge: take arguments as annotated context objects 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

filemerge: make `labels` a required arg for `_premerge()` 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

filemerge: remove unnecessary check for empty string Looking at the statement just before, the string is clearly never empty (or otherwise falsy). Differential Revision: https://phab.mercurial-scm.org/D12011

tests: also test spaces in conflict marker labels 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

blackbox: change year in logs to ISO 8601 format 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

blackbox: add milliseconds to blackbox logs by default 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

blackbox: correct date format doc Differential Revision: https://phab.mercurial-scm.org/D12004

revlog: fix a bug where transaction can be aborted partially Fix a repo corruption bug caused by a partial transaction rollback. Differential Revision: https://phab.mercurial-scm.org/D12009

revlog: demonstrate a bug where transaction can be aborted partially Differential Revision: https://phab.mercurial-scm.org/D12008

branching: merge with stable

rust: fix build errors on darwin 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