Martin von Zweigbergk <martinvonz@google.com> [Mon, 24 Jan 2022 08:35:14 -0800] rev 48594
relnotes: add note about changed labels texts
Differential Revision: https://phab.mercurial-scm.org/D12085
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jan 2022 13:48:48 -0800] rev 48593
graft: attempt to make merge labels more helpful
Differential Revision: https://phab.mercurial-scm.org/D12025
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jan 2022 13:49:11 -0800] rev 48592
shelve: attempt to make merge labels more helpful
Differential Revision: https://phab.mercurial-scm.org/D12024
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Jan 2022 13:48:18 -0800] rev 48591
histedit: attempt to make merge labels more helpful
Differential Revision: https://phab.mercurial-scm.org/D12023
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jan 2022 13:23:49 -0800] rev 48590
update: set custom conflict label for base commit
Differential Revision: https://phab.mercurial-scm.org/D12022
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jan 2022 15:04:55 -0800] rev 48589
merge: set custom conflict label for base commit
Differential Revision: https://phab.mercurial-scm.org/D12021
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jan 2022 14:57:15 -0800] rev 48588
rebase: set custom conflict label for base commit
Differential Revision: https://phab.mercurial-scm.org/D12020
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 11:06:52 -0800] rev 48587
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 16:16:05 -0800] rev 48586
filemerge: pass `simplemerge.MergeInput` to tool functions
Differential Revision: https://phab.mercurial-scm.org/D12018
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 14:42:50 -0800] rev 48585
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 14:13:12 -0800] rev 48584
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 13:43:43 -0800] rev 48583
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
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Jan 2022 10:32:11 +0100] rev 48582
helptext: add missing newline to Rust helptext
This makes it so the list renders properly.
Differential Revision: https://phab.mercurial-scm.org/D12007
Martin von Zweigbergk <martinvonz@google.com> [Mon, 24 Jan 2022 21:17:04 -0800] rev 48581
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
Martin von Zweigbergk <martinvonz@google.com> [Mon, 24 Jan 2022 21:12:19 -0800] rev 48580
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 11:17:09 -0800] rev 48579
filemerge: remove unused arguments from `_merge()`
Differential Revision: https://phab.mercurial-scm.org/D12014
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 11:00:30 -0800] rev 48578
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 09:04:39 -0800] rev 48577
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 14:46:16 -0800] rev 48576
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
Martin von Zweigbergk <martinvonz@google.com> [Thu, 20 Jan 2022 23:07:35 -0800] rev 48575
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
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 17 Jan 2022 21:20:46 -0500] rev 48574
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
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 17 Jan 2022 21:00:33 -0500] rev 48573
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
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 17 Jan 2022 20:47:46 -0500] rev 48572
blackbox: correct date format doc
Differential Revision: https://phab.mercurial-scm.org/D12004
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 20 Jan 2022 14:06:36 +0000] rev 48571
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
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 20 Jan 2022 14:02:58 +0000] rev 48570
revlog: demonstrate a bug where transaction can be aborted partially
Differential Revision: https://phab.mercurial-scm.org/D12008
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Jan 2022 10:27:13 +0100] rev 48569
branching: merge with stable
Dan Villiom Podlaski Christiansen <danchr@gmail.com> [Thu, 30 Dec 2021 13:25:44 +0100] rev 48568
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
Simon Sapin <simon.sapin@octobus.net> [Mon, 17 Jan 2022 12:50:13 +0100] rev 48567
rust: Fix outdated comments in OwningDirstateMap
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jan 2022 09:28:44 -0800] rev 48566
merge: consider the file merged when using :merge-{local,other}
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 <martinvonz@google.com> [Fri, 14 Jan 2022 08:44:36 -0800] rev 48565
simplemerge: delete unused exception class `CantReprocessAndShowBase`
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