Page MenuHomePhabricator

copies: follow copies across merge base without source file (issue6163)
ClosedPublic

Authored by martinvonz on Tue, Jul 2, 1:13 PM.

Details

Summary

As in the previous patch, consider these two histories:

@  4 'rename x to y'
|
o  3 'add x again'
|
o  2 'remove x'
|
| o  1 'modify x'
|/
o  0 'add x'

@  4 'rename x to y'
|
o  3 'add x again'
|
| o  2 'modify x'
| |
| o  1 'add x'
|/
o  0 'base'

We trace copies from the 'modify x' commit to commit 4 by going via
the merge base (commit 0). When tracing file 'y' (_tracefile()) in the
first case, we immediately find the rename from 'x'. We check to see
if 'x' exists in the merge base, which it does, so we consider it a
valid copy. In the second case, 'x' does not exist in the merge base,
so it's not considered a valid copy. As a workaround, this patch makes
it so we also attempt the check in mergecopies's base commit (commit 1
in the second case). That feels pretty ugly to me, but I don't have
any better ideas.

Note that we actually also check not only that the filename matches,
but also that the file's nodeid matches. I don't know why we do that,
but it was like that already before I rewrote mergecopies(). That
means that the rebase will still fail in cases like this (again, it
already failed before my rewrite):

@  4 'rename x to y'
|
o  3 'add x again with content X2'
|
o  2 'remove x'
|
| o  1 'modify x to content X2'
|/
o  1 'modify x to content X1'
|
o  0 'add x with content X0'

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

martinvonz created this revision.Tue, Jul 2, 1:13 PM
This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.
yuja added a subscriber: yuja.Thu, Jul 11, 8:15 PM
We trace copies from the 'modify x' commit to commit 4 by going via
the merge base (commit 0). When tracing file 'y' (_tracefile()) in the
first case, we immediately find the rename from 'x'. We check to see
if 'x' exists in the merge base, which it does, so we consider it a
valid copy. In the second case, 'x' does not exist in the merge base,
so it's not considered a valid copy. As a workaround, this patch makes
it so we also attempt the check in mergecopies's base commit (commit 1
in the second case). That feels pretty ugly to me, but I don't have
any better ideas.

Maybe better to add some inline doc?