Tue, 07 Dec 2021 17:48:50 -0800 simplemerge: make `localorother` a "mode" instead of a separate thing
Martin von Zweigbergk <martinvonz@google.com> [Tue, 07 Dec 2021 17:48:50 -0800] rev 48509
simplemerge: make `localorother` a "mode" instead of a separate thing `simplemerge()` takes a `mode` argument, which can be "union", "merge" or "mergediff", and a `localorother` argument, which can be `None`, "local", or "other". The two options are not at all orthogonal -- most combinations don't make sense. Also, at least "union", "local", and "other" are very closely related. Therefore, it makes sense to combine them into one. It probably makes sense to split the `mode` argument into `resolve` and `marker_style`, where the former can be `None`, "union", "local", or "other", and the latter can be "merge", "merge3", "mergediff", or "minimize". This is a good step in that direction whether or not we end up doing that. Differential Revision: https://phab.mercurial-scm.org/D11887
Tue, 07 Dec 2021 14:11:58 -0800 simplemerge: avoid a call to `pycompat.strkwargs()`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 07 Dec 2021 14:11:58 -0800] rev 48508
simplemerge: avoid a call to `pycompat.strkwargs()` Differential Revision: https://phab.mercurial-scm.org/D11886
Mon, 06 Dec 2021 23:17:43 -0800 simplemerge: stop merging file flags
Martin von Zweigbergk <martinvonz@google.com> [Mon, 06 Dec 2021 23:17:43 -0800] rev 48507
simplemerge: stop merging file flags As 384df4db6520 (merge: merge file flags together with file content, 2013-01-09) explains, we shouldn't do a 3-way merge of the symlink. However, since 84614212ae39 (flags: actually merge flags in simplemerge, 2020-05-16), we do that in `simplemerge.simplemerge()`. What's more, the merging of the executable flag there isn't actually necessary; it was made a no-op by the very next commit, i.e. 4234c9af515d (flags: read flag from dirstate/disk for workingcopyctx (issue5743), 2020-05-16). I found the overall flag-merging code (not the bit in `simplemerge.py`) very hard to follow, but I think I now finally understand how it works. `mergestate.resolve()` calculates the merged file flags and sets them on the local side of the merge (confusingly by calling `_restore_backup()`). Then it calls `filemerge.filemerge()`, which in turn calls `simplemerge.simplemerge()` (if premerge is enabled). That means that the flags on the local side `fcs.flags()` are already correct when the flag-merging code in `simplemerge.simplemerge()` runs. Interestingly, that code still works when the local side already has the merged value, it just doesn't change the value. Here's a truth table to explain why: ``` BLOMCAR 0000000 0011111 0101011 0111111 1000000 1010000 1100000 1111101 ``` B: Base L: Local O: Other M: Merged flags from `mergestate.resolve()`, i.e. what's called "local" when we get to `simplemerge.simplemerge()` C: `commonflags` in `simplemerge.simplemerge()`, i.e. `M & O` A: `addedflags` in `simplemerge.simplemerge()`, i.e. `(M ^ O) - B` R: Re-merged flags `simplemerge.simplemerge()`, i.e. `C | A` As you can see, the re-merged flags are always unchanged compared to the initial merged flags (R equals M). Therefore, this patch effectively backs out 84614212ae39. (I might later refactor this code to have the flags explicitly passed in.) `simplemerge.simplemerge()` is also called from `contrib/simplemerge.py`, but that code never passes any flags. Differential Revision: https://phab.mercurial-scm.org/D11879
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 tip