Git rename but GitHub shows it as added file and deleted file

[shirady]

Select Topic Area

Bug

Body

Hi,
The issue in detail:

1. I moved the file into a new directory (I dragged the file to the new directory using VS Code UI).
2. Git recognized this change as a deleted file and a new file, I added both changes before I commit.
3. I run git status, and you can see that the file test_ceph_s3.js was recognized now as renamed
4. I commit and push to the PR - but GitHub shows test_ceph_s3.js as added and deleted file.

Note: this was not the only file that I moved and renamed in this PR, all the other file was recognized as renamed in Git and also in GitHub.
I read here that I should have used git mv (which as you can read above I didn't use...), and maybe it would fix it, but I'm not sure it would work since Git recognized the change of the file as renamed.

Thanks,
Shira

[LuisContrerasGlz]

try using the git mv command to explicitly rename the file, rather than simply moving it in the file system. This will help Git track the file's history more accurately.

[shirady]

Hi @LuisContrerasGlz
Git tracked the file history, it's GitHub that didn't...

[LuisContrerasGlz]

Oh I see sorry about the confusion

[airtower-luna]

Git is very good about detecting when files are renamed, and as you described it did for you. I assume this is simply a limitation of the GitHub UI.

[shirady]

I just wonder what will happen, since it's a shared project, and we use the feature of 'Blame' - in case it detects it as delete and add I'm loosing all the previous changes.

[airtower-luna]

The git blame documentation says this:

The origin of lines is automatically followed across whole-file renames (currently there is no option to turn the rename-following off). To follow lines moved from one file to another, or to follow lines that were copied and pasted from another file, etc., see the -C and -M options.

So it should just work, and if it doesn't it's definitely a bug that the devs should want to fix. 🙂

[spenserblack]

Just curious, were you using Windows when you did this? Git on Windows can automatically convert line endings depending on settings, so perhaps the commit tracks different line endings than the original file had.

[zdenkolini]

can't believe this is still unresolved

[skylupop]

This is a big issue, in my opinion, and since GIT is actually capable to track the file renaming I can't understand why GitHub cannot.

[thomasttvo]

happening to me on Mac

[tim-phillips]

This is not an answer! @shirady, could you please unmark as an answer so that this may get the attention it deserves?

[shirady]

I unmark it @tim-phillips , I think it was marked by mistake

[Fred-AtelierSalvetat]

Hi
I have the same issue:

1. Move files in a commit
   -> Github status was correct
2. Modify files content in a second commit
   -> Commit appears correctly on GitHib
   -> Files Changed" present files as deleted/created.
   -> Line counts is then erroneous hence bad metrics :/

[jabielecki]

Actually, you can go to GH webUI pull request Files tab and render changes from selected commits (shift+click). The diff of a file renders up to a certain threshold of changed lines of text. Over a threshold, the webUI gives up.

1. git mv, content unchanged -> GH shows diff
2. git mv, a few lines of content changed -> GH shows diff
3. git mv, +270/-230 lines changed for a 900 line file -> GH hides diff, but you can still click to show it
4. git mv, more lines than that changed -> GH shows separate create+delete (+900/-900), without a diff

Seen on GitHub Enterprise Server 3.9.4

[gmnikhil]

Facing the same issue. git status shows renamed but github ui showing as created / deleted

[thomasttvo]

Please fix this issue. This heavily impacts productivity of code review whenever it happen.

[JanakarM]

Impacted.

[JanakarM]

Can the right person remove marked as answer so that it could be looked after in priority?

[TamaraFinogina]

Same here. Git can recognize renaming, but github ui showing the same file as deleted/added

[Quanalogy]

We are also hit by this- really what the .... is going on.
On linux doing:

git mv file file2
git commit -am "rename file to file2"
echo "changes to file 2" >> file2
git commit -am "Changes to file2"
git push

This certainly was not an issue on gitlab.

The kicker is if you look at the commit where you rename the file you actually see that it is renamed without changes, looking at the commit where I did the changes to the file for itself also shows this correctly - however in the overview with both commits it suddently is deleted and then created...

@spenserblack any comment on that?

[spenserblack]

however in the overview with both commits it suddently is deleted and then created...

For the sake of this conversation I'll call the commit before the move 1111111, the move commit 2222222, and the commit with file changes 3333333.

GitHub could perhaps be smarter by resolving the diffs between commits individually, that is checking 1111111..2222222 then 2222222..3333333 to follow file renames. But this is a result of diffing 1111111..3333333.

I'll try to answer this to be best of my knowledge, but keep in mind that I may be wrong about some things.

There are a few version control systems that track file renames. Git is not one of them (at least not completely). Here's a detailed comparison: https://en.wikipedia.org/wiki/Comparison_of_version-control_software#Features

When Git looks at 1111111..2222222, it thinks "I see that when file1 was deleted, and file2 was created with very similar contents, so this is probably a rename." But when Git looks at 1111111..3333333, it's resolving the "total" difference between those two commits, and it thinks "I see that file1 was deleted, and now file2 exists with very different contents, so file1 was deleted and file2 was created."

Here's a quote from the Wikipedia page comparing VCS:

Git does not explicitly track renames, because by design it does not track individual files. Renames and split of source files are detected after the fact, if the file content does not change dramatically.

source