Tue, 18 Jan 2022 13:23:49 -0800 update: set custom conflict label for base commit
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
Tue, 18 Jan 2022 15:04:55 -0800 merge: set custom conflict label for base commit
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
Tue, 18 Jan 2022 14:57:15 -0800 rebase: set custom conflict label for base commit
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
Thu, 20 Jan 2022 11:06:52 -0800 simplemerge: take over formatting of label from `filemerge`
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
Thu, 20 Jan 2022 16:16:05 -0800 filemerge: pass `simplemerge.MergeInput` to tool functions
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
Thu, 20 Jan 2022 14:42:50 -0800 filemerge: work with `simplemerge.MergeInput` in `filemerge()`
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
Thu, 20 Jan 2022 14:13:12 -0800 filemerge: always define a "base" label
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
Thu, 20 Jan 2022 13:43:43 -0800 filemerge: set default labels a little earlier
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 tip