This was discovered when rebasing https://phab.mercurial-scm.org/D1429 A minimal test case: $ cat >> $HGRCPATH << EOF > [extensions] > rebase= > EOF $ hg init $ cat > A <<EOF > 1 > 2 > 3 > EOF $ chmod +x A $ hg commit -m A -A A $ cat > A <<EOF > 1 > 2 > 2.5 > 3 > EOF $ hg commit -m A-Modify $ hg update '.^' 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg mv A B $ cat > B <<EOF > 1 > 1.5 > 2 > 3 > EOF $ hg commit -m A-Rename-Modify created new head $ hg rebase -r . rebasing 2:f548ec46c01e "A-Rename-Modify" (tip) merging A and B to B saved backup bundle to $TESTTMP/.hg/strip-backup/f548ec46c01e-b9f63412-rebase.hg (glob) $ hg log -r . -p --config diff.git=1 changeset: 2:bdd538f593ee tag: tip user: test date: Thu Jan 01 00:00:00 1970 +0000 summary: A-Rename-Modify diff --git a/A b/B old mode 100755 new mode 100644 <<<< UNEXPECTED rename from A rename to B --- a/A +++ b/B @@ -1,4 +1,5 @@ 1 +1.5 2 2.5 3
Bug was inactive for 150 days, archiving
This bug still exists and actually has 3 variantes, patches series coming.
Fixed by https://mercurial-scm.org/repo/hg/rev/4234c9af515d Pierre-Yves David <pierre-yves.david@octobus.net> flags: read flag from dirstate/disk for workingcopyctx (issue5743) In 491855ea9d62, various piece of code are moved from committablectx to workingctx. The reason given is "These read from the dirstate, so they shouldn't be used in other subclasses." At least for `flags` this change introduce a bug, because the value flags end up being read from `_manifest` disregarding the actual state in the working copy (ie: on disk). When merging exec flag change with renames, this means a new files (the local content, renamed) is properly written on disk, with the right flags, but the flags part is later ignored when actually reading flags during merge. It is not clear to me why the `flags` function was moved, because the code does not actually hit the dirstate (the reason given in the changeset description). So I am moving it back to were it comes from and we use a simpler version of that code (that hit the dirstate everytime) in workingcopyctx. This fix the last know bug with merging rename and executable byte changes. Other similar bug might be lurking in 491855ea9d62, but I have not investigated them. Differential Revision: https://phab.mercurial-scm.org/D8534 (please test the fix)
Bug was set to TESTING for 7 days, resolving
Fixed by https://mercurial-scm.org/repo/hg/rev/58a3be48ddd2 Martin von Zweigbergk <martinvonz@google.com> 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 (please test the fix)