This demonstrates the bug $ hg init $ echo -e '1\n\2' > file $ hg ci -Am initial $ hg mv file file2 $ echo -e '3\n\4' > file2 $ hg ci -m 'move and modify' $ hg split At the last step, select just the first line (removing the line "1") and press "c" to confirm. The split completes, putting everything in a single commit.
Bug was inactive for 150 days, archiving
Similarly, it looks like you can split a file deletion, but it ends up deleting the entire file: $ hg init $ echo -e '1\n\2' > file $ hg ci -Am initial $ hg rm file $ hg ci -m delete $ hg split Now select just one of the lines. The split completes, putting the entire deletion in a single commit.
I've just mailed fixes for splitting/interactively committing copies and renames. I haven't fixed interactive revert (it's not really affected by it since it doesn't allow partial reverts of copied/renamed files, it seems?). I haven't fixed the file deletion case, and don't plan on doing more work here; we may want to split that out to another issue? File deletion only appears splittable in the curses UI, in the text UI, it asks: diff --git a/qux b/qux deleted file mode 100644 examine changes to 'qux'? (enter ? for help) [Ynesfdaq?] y and then just spawns the commit message editor immediately instead of letting me modify the patch at all, so it's a different underlying issue, I believe.
Fixed by https://mercurial-scm.org/repo/hg/rev/3cf091843b4f Kyle Lippincott <spectral@google.com> split: handle partial commit of renames when doing split or record (issue5723) When using split or record, using either interface (text or curses), selecting portions of the file to be committed/recorded did not work; the entire file was treated as having been selected. This was because the logic for handling partial application of the patches relies on knowing what files are "new with modifications" and it doesn't treat "rename destination" as "new". There was a complicating issue, however. We're relying on the patch header specifying the copy from/to information, which works as long as the 'copy from' file is there. In the case of renames, however, the 'rename from' file is *not* there, so we need to add it back. Differential Revision: https://phab.mercurial-scm.org/D6768 (please test the fix)
Bug was set to TESTING for 7 days, resolving
*** Bug 6047 has been marked as a duplicate of this bug. ***