Nick Taylor

Posted on Feb 7, 2019 • Updated on Apr 17, 2022 • Originally published at iamdeveloper.com

Git file renaming issues (deleting/adding instead of renaming)

#help #git #github

Hey folks, I need a little help as I've kind of reached the extend of my gitfu.

I'm working on a PR and I didn't realise at the time, but some files were committed as a deleted file (the original file) and a new file (the rename of the old file) when I renamed some of them. I was asked to ensure it's renamed in Git so as to preserve the history. Fair enough.

So if you look at the comments in the PR (I link to the first one about renaming in there), you'll see that I've done the following in a few different was but here is the gist of it:

Recovered the deleted file, source/libs/icons.js
Deleted the new file, source/libs/icons.tsx
Commit those changes
Run a git mv source/libs/icons.js source/libs/icons.tsx
Push to the remote, and the PR shows it as a file rename with no file changes.
The next commit is putting back the changes I had in source/libs/icons.tsx.
Push to the remote, and the PR shows that source/libs/icons.js has been deleted and source/libs/icons.tsx has been added.

I've even had one of the maintainers of the repo try to give me a hand, but he ends up in the same predicament as I do.

Any suggestions gitfolk?

Photo by Markus Spiske on Unsplash

Top comments (14)

Jesse Phillips • Feb 7 '19

Git has no rename, just like in Linux. Git facilities a rename through heuristics of a delete and add in the same commit. The file can be modify on the other end, but if it differs to much it will consider it a new file.

Jesse Phillips • Feb 7 '19

See, history does know it is the same, github.com/sindresorhus/refined-gi...

But it seems the review tool or the git diff command used is recalculating the heuristics, which makes sense because git prefer to ignore individual Commits when diffing

Nick Taylor • Feb 7 '19

Yeah I see that in the history. But the next commit changes the content and that's when it thinks it's an add/delete. That's what's confusing me. So as you say, it is keeping the history, it's just the diffing tool confusing me.

DeChamp • Feb 7 '19

So one thing I noticed in the past is, both with GitHub and gitlab, it can sometimes have issues with this. I don’t know if it’s cache or what but it would be confused. It could be github/gitlab. Can you have someone else do a pull and check locally?

Nick Taylor • Feb 7 '19

Sounds like this could be the case and yes, I did have someone else pull and check locally. They tried as well. Good to know that it might just be on the GitHub end.

DeChamp • Feb 7 '19

So two things. Give it time and check later. Second is create a new repo on the same service and see what it shows. That should prove the theory.

Martin Huter • Feb 8 '19 • Edited

Hey have you already found a solution of the problem? I ran to something similar in my past and solved it with reseting the branch before the renaming. Just do the renaming in one commit, and all the changes in the next one.

If you need I could showcase it for you.

Nick Taylor • Feb 8 '19

In the initial post, there is a link to the PR. It's already merged now. We did it in two steps if you look at the commit history. I'm still not sure why we couldn't get it to work properly. Any insight would be great as I'd be curious for future PRs.

Martin Huter • Feb 8 '19 • Edited

Hey I tinkered a little example:

github.com/mgh87/git-rename-example

GitHub only shows the rename properly if you review the specific commit. ( In the feature/rename )

But the important thing in git to follow the history of a file is the log command:
git log --oneline --follow -- new-name.txt

If you clone the repository and try this command out once in feature/rename and feature feature/delete-add you see that in the branch where the rename is lost only the last commit represents the history of the file.

I hope this explanation is detailed enough.

P.s.: You can use rebase -i to split up the commits if it is not in recent history. But keep in mind that this is a rewrite history and you can produce even more complex issue. I recommend to apply such a thing only in feature branches where so one else did build on the changed history.

If anyone is interested how the rebase approach works, I can make something up and document it as a little blog post.

P.s. (2): GitHub uses a heuristic to determine, if a file is just renamed or delted+new. I try to have a single commit to rename the files to keep the history.

Roman Kirpichnikov • Oct 2 '19 • Edited

@nickytonline i find solution and create gist
gist.github.com/trddddd/69f1f13449...

step for fix it

git filter-branch -f --tree-filter 'if [ -f old_file ]; then mkdir -p new_dir && mv old_file new_file; fi'
mv old_file new_file
gaa && gcmsg 'perfect'

Nick Taylor • Oct 2 '19

Awesome. Thanks for sharing. 😎

Mac Siri • Feb 7 '19

A rather wild guess here, but could it be because you've changed the file type instead of the file path? I've recently made some changes to the file path and Github was able to show proper diff.

Nick Taylor • Feb 10 '19 • Edited

We ended doing it two PRs as they really wanted to get the PR in, but I'm definitely going to go over all the advice from @jessekphillips , @dechamp and @mgh87 . Thanks so much for chiming in to lend a hand.

And the good news is, my PR is merged!

Sindre Sorhus

@sindresorhus

The Refined GitHub browser extension just passed 1000 commits and we also just finished the transition to TypeScript, thanks to @nickytonline and @bfred_it 👏 github.com/sindresorhus/r…

15:26 PM - 08 Feb 2019

666

I'm really happy about this contribution as I used the Refined GitHub extension all the time.

sindresorhus / refined-github

Browser extension that simplifies the GitHub interface and adds useful features

Refined GitHub

Browser extension that simplifies the GitHub interface and adds useful features

We use GitHub a lot and notice many annoyances we'd like to fix. So here be dragons.

Our hope is that GitHub will notice and implement some of these much needed improvements. So if you like any of these improvements, please email GitHub support about doing it.

GitHub Enterprise is also supported. More info in the options.