Skip to main content

Renaming Files in Git

Renaming Files

I recently had to rename a lot of files in brf-mode for submission into MELPA. These files have 10+ years of version control history I wanted to keep. In the process I realised retaining all that history in Git isn't as simple as I thought 😀

I thought it was as simple as using git mv rather than filesystem mv and Git would know everything had been renamed. It turns out I was wrong and I should have known that from my knowledge of how Git works 😖

In reality, Git works by storing snapshots rather than file or directory metadata and git mv is just a convenience shortcut for typing:

$ mv <old name> <new name>
$ git rm <old name>
$ git add <new name>

That's all there is to it!

Now the "magic" happens when you git log or git blame a file and Git works out the file was renamed by diffing the contents.  If files have the same contents (within a certain threshold %) it thinks a rename happened. See here in the Git SCM Book for the gory details.

A consequence of this is if you rename files and then make a whole load of changes to the contents of those files, Git will not recognise this as a rename.

Therefore it is important to make the rename in one commit and any changes to the contents in another commit.

Of course Git being Git, there is a further wrinkle. While git blame will follow renames and give you a consistent annotation by default, git log does not.  git log will only show history to the last rename unless you supply the --follow argument. You really couldn't make this stuff up...

You can work around this by setting log.follow in .gitconfig.
However when I'm doing command line Git I like to have full control of what I'm doing, so instead of doing that I just tell Emacs VC to follow by default:

(setq vc-git-print-log-follow t)

Moving Files

Unfortunately moving files between directories creates further problems - history is only partially retained. git log --follow allows you to see the history of the moved files, but git diff, bisect etc can't find the revisions. You can still diff commits from the top-level log, just not for an individual file. Hopefully future Git revisions will fix this - until then the only way around it I know about is to destructively edit the commit history with filter-branch etc. That will have to be the subject of a future post 😀

Labels:

Comments

Post a Comment

Popular posts from this blog

My Work in new Top Trumps Birds of Prey Pack

The new Top Trumps "Birds of Prey" pack has my picture illustrating the Secretary Bird card 😀 Here's the original picture: From Flickr
Post a Comment
Read more

On BBC Springwatch !

BBC Springwatch featured one of my Goldfinch pictures last night: Goldfinch on Springwatch Shame they spelt my name wrong though! See the original on Flickr.
Post a Comment
Read more

Emacs and MacOS Catalina

Catalina introduced a lot of security changes and the most intrusive is probably all the popups asking to give permission for apps to access directories under Home, like Documents. Worse still, apps which weren't written to handle the new security measures might just fail silently with no clues for the user. A solution is to give apps like Emacs "Full Disk Access" under "Security & Privacy" in Preferences, to give unfettered access to your files and avoid all the popups and silent failures. Sounds good, but that doesn't actually work for Emacs because "Emacs" in the app bundle is actually a Ruby script which decides which flavour of Emacs executable to run. This never mattered before, but it does under Catalina because MacOS thinks the executable is /usr/bin/ruby . Conventional wisdom is therefore to give "Full Disk Access" to Ruby. While this does work, I've always been uncomfortable giving all Ruby scripts full access...
Post a Comment
Read more