files that are effectively renamed are showed as deleted/new

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
2 years ago
a year ago

People

(Reporter: jmaher, Unassigned)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
a frustrating review experience:
https://reviewboard.mozilla.org/r/82058/diff/3/
Created attachment 8872782 [details]
File renames in Phabricator-Differential

FYI Phabricator appears to handle proper renames (that is, with "hg mv") correctly; see attached screenshot.
(In reply to Mark Côté [:mcote] from comment #1)
> Created attachment 8872782 [details]
> File renames in Phabricator-Differential
> 
> FYI Phabricator appears to handle proper renames (that is, with "hg mv")
> correctly; see attached screenshot.

So does Review Board, the linked review request was due to "hg mv" not being used. I wonder what phabricator shows in that case? I'm guessing probably a delete and add like Review Board.
(In reply to Steven MacLeod [:smacleod] from comment #2)
> So does Review Board, the linked review request was due to "hg mv" not being
> used. I wonder what phabricator shows in that case? I'm guessing probably a
> delete and add like Review Board.

I would guess this too. But Phabricator has reinvented enough aspects of version control that I wouldn't be surprised if they do copy and rename detection. Although it only has access to the files touched by the commit, so it can't detect copies from unmodified files like git's --find-copies-harder can.
Ah I see.  Yeah, it shows the same as Review Board.  I believe this is technically correct, since, as you imply, "hg mv X Y" is technically different from "cp X Y; hg rm X; hg add Y".  Due to the fact that these are, for whatever reason, different operations in hg, I'm WONTFIXing this.  I think reviewers should r- a patch that should use "hg mv" but doesn't.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.