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