graft: fix --base value to be saved in state file 'True' just works because it is treated as an integer revision '1' and only the truthiness of the basectx is important. If multiple source revisions were supported with --base, the resumed graft operation would go wrong.

flags: also test merge with executable bit removed This might catch more bug in the future. Differential Revision: https://phab.mercurial-scm.org/D8536

flags: also test the removal of the exec flag Differential Revision: https://phab.mercurial-scm.org/D8535

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

flags: actually merge flags in simplemerge Since b86fc43e4b73, the local flag were blindly taken. This resulted in bug when rename are involved. exec flag change are now properly merged (when merged from the rename side). Another bug is affecting this when merging from the side without the rename. Differential Revision: https://phab.mercurial-scm.org/D8533

flags: add a test for merging exec flag change with rename and file change Changing the file activate other code path that also have bugs… There are two distinct bugs depending of which side of the merge you stand on. They both leading to exec flag loss. We add tests for both, the fix are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8532

flags: account for flag change when tracking rename relevant to merge There are some logic filtering rename to the one relevant to the merge. That logic was oblivious of flag change, leading to exec flag being dropped when merged with a renamed. There are two others bugs affecting this scenario. This patch fix the was where there is not modification involved except for the flag change. Fixes for the other bug are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8531

flags: also test merging a rename with and exec flag change This case is currently buggy and was not tested. This is probably a quite old regression. The next changeset fix this case. Move exec+rename related bug will gain a test later. To highlight the expected behavior the currently missing line are marked with (false !) and the bad one with (true !) note: we should probably gain explicit "test bool" for this usecases. Differential Revision: https://phab.mercurial-scm.org/D8530

flags: introduce explicit testing for merging change to exec flag It turns out that we do not seems to test the simple case for merging exec flag changes. More advanced case are test (merging exec flag without a common ancestors, merging with a symlink, etc…) but not the basic. We are about introduce various fixes to merging flag change across renames, having the most basic case tested first seems useful. note: We are only testing "adding" an exec flag here, not removing it. We introduce basic test on stable and will consolidate them on default. Differential Revision: https://phab.mercurial-scm.org/D8529

graft-state: save --base in graft's state, fixing bug with graft --continue Without this change, running graft --continue after grafting a merge commit using --base (and encountering conflicts) will output "skipping ungraftable merge revision" even though we specified a base in the initial graft command. Graft's improve behaviour is reflected in test-graft.t. Differential Revision: https://phab.mercurial-scm.org/D8578