Grafting a mv with edits over an existing mv with different edits causes the log -f history to not show the second edit. hg init foo cd foo touch a && hg ci -Aqm a hg mv a b echo b1 >> b hg ci -Aqm b1 hg up 0 hg mv a b echo b2 >> b hg ci -Aqm b2 hg graft 1 hg log -f b Expected: changeset: 3:1edcf609cbb7 summary: b1 changeset: 2:d98d3276e1cd summary: b2 changeset: 0:01f02e8249d2 summary: a Actual: changeset: 3:1edcf609cbb7 summary: b1 changeset: 0:01f02e8249d2 summary: a This is caused by localrepo._filecommit attempting to find copy information by traversing the commit graph in search of the last place that had the source file. It finds the original 'a' commit and makes that the filelog parent of the incoming change. The entire localrepo._filecommit() copy tracing logic is broken. For example: The look up is 'self[None].ancestors()' but localrepo._filecommit is called from commitctx which is totally independent of the working copy. So arbitrary memctx commits are doing copy tracing relative to the working copy position. In my opinion we should not be doing any copy tracing at all here. If the copy source file is not in either of the parent manifests, it's not a copy. If graft wants to be smart about importing copies, that logic should exist in graft/merge and it should set up the dirstate appropriately before committing.
Fixed by http://selenic.com/repo/hg/rev/a43fdf33a6be Ryan McElroy <rmcelroy@fb.com> commit: remove reverse search for copy source when not in parent (issue4476) Previously, we had weird, nonsensical behavior when committing a file move with a missing source. This removes that weird logic and tests that the bug this strange behavior caused is fixed. Also adds a longish comment to prevent some poor soul from accidentally re-implementing the bug in the future. (please test the fix)
Bug was set to TESTING for 7 days, resolving