2089

I have changed a few files name by de-capitalize the first letter, as in Name.jpg to name.jpg. Git does not recognize this changes and I had to delete the files and upload them again. Is there a way that Git can be case-sensitive when checking for changes in file names? I have not made any changes to the file itself.

Gil Shulman
  • 20,909
  • 3
  • 13
  • 4
  • 5
    @nif this isn't quite correct, Git actually has a configuration setting that controls whether or not it ignores case sensitivity. –  Jul 16 '13 at 22:49
  • 10
    See http://stackoverflow.com/a/24979063/6309: since git 2.0.1, a simple `git mv` works. – VonC Mar 27 '15 at 06:44
  • possible duplicate of [Git: Changing capitalization of filenames](http://stackoverflow.com/questions/10523849/git-changing-capitalization-of-filenames) – KyleMit Aug 20 '15 at 12:22
  • @nif Just wanted to add (a few years later ;) that HFS _can_ be made case sensitive, but it's not case sensitive by default. I have a separate 65 GiB partition formatted with case sensitive HFS, which I use for my `git` working copies. Spares a lot of my sanity, I must admit... – Per Lundberg Feb 09 '17 at 12:41

22 Answers22

2293

As long as you're just renaming a file, and not a folder, you can just use git mv:

git mv -f yOuRfIlEnAmE yourfilename

(As of a change in Git 2.0.1, the -f flag in the incantation above is superfluous, but it was needed in older Git versions.)

Mark Amery
  • 143,130
  • 81
  • 406
  • 459
Keith Smiley
  • 61,481
  • 12
  • 97
  • 110
  • 13
    this gives me 'source directory is empty' while it is not – WiseStrawberry Jul 19 '14 at 13:10
  • Tried that and got `fatal: renaming '...' failed: File exists`. I'm doing that in Ubuntu virtual machine, which runs in OSX – HEKTO Sep 28 '16 at 16:26
  • 12
    Using MacOS here (case-insensitive FS) and -f worked! Thanks for the tip – caesarsol Dec 15 '16 at 18:08
  • @WiseStrawberry if you have spaces in the file path, trying wrapping it in quotes. – StoriKnow Mar 22 '17 at 14:22
  • 20
    Don't forget to give the full file path. Obvious, I know, but got me for a while – rickrizzo Aug 15 '17 at 16:03
  • As WiseStrawberry pointed out, this may give a "source directory is empty" error when applied to folders in the root git directory. (subfolders seem to work fine) – Stevoisiak Aug 29 '17 at 13:32
  • 3
    This isn't working for me on a directory i want to rename (`failed: Invalid argument`) with full file path and without. weird. – Damon Feb 23 '18 at 21:50
  • 2
    You can't move directories with `git mv`. You'll need to do each file in the directory if you are trying to modify the case of a directory name. – Sam Soffes Sep 14 '18 at 23:15
  • 3
    Strangely enough, to get this to work on Mac OS, I first had to rename a given file 'TestCase.ts' to 'TestcaseSomething.ts', commit it, then correct it to the desired result 'Testcase.ts' before a final commit and push. – Patrick Nov 21 '18 at 12:00
  • 18
    To the top voted comment: you *do* need the `-f` switch with the latest git (2.18) otherwise you could get the `fatal: destination exists` error. – DeepSpace101 Feb 15 '19 at 17:53
  • git mv -f {O,o}ldFileNameCase – Brian Peterson Jan 09 '20 at 18:11
  • If I do this I can see the file has been removed from Git but it doesn't track the new file. – Amy Pellegrini Apr 16 '20 at 19:37
  • 1
    Worked perfectly on Mac OS Catalina with git 2.24.0 – Liran H Jun 16 '20 at 08:38
  • 10
    It's important to note that this doesn't work if you're trying to rename a directory instead of a file. If you need to rename a directory, you have to do a `git mv` for each file in the directory instead. – Chris Charabaruk Nov 18 '20 at 18:01
  • FYI: I am on git 2.29.2, running on macOS, and it still requires the -f to do a case sensitive file rename – Matthew Joughin Aug 24 '21 at 05:50
  • 1
    This worked, but note that it might not show up properly immediately. For me it did not show up correctly in GitKraken on Windows, but did show up after pushing the commit to the remote repository and viewing with a Git client, and it did show up when viewing the commit with GitKraken on a case-sensitive platform (Linux). – Aaron Franke Nov 30 '21 at 21:57
  • Some issue are like Eternal Pandemic. They affect the world for ever, lol. Worked for me on moving a `Signin.js` to `SignIn.js`. – KeitelDOG Jun 19 '22 at 17:07
  • Thank you! We had a file that was committed and accidentally changed to uppercase. Windows, being case insensitive, wasn't able to pull both files down, so I couldn't delete the other one or anything like that. 'moving' the file in this way worked. This saved a lot of time. – adprocas Jul 14 '22 at 15:02
  • If you're seeing `failed: Invalid argument` when trying to rename a directory then rather than renaming each file, running the `git mv -f` command twice was faster for me. Example: `git mv -f Oldname _Oldname && giit mv -f _Oldname newname` (you have to change more than just the case for it to run) – James Hooper Jul 27 '22 at 07:06
  • Now, it is year 2023, and I'm using git `git version 2.40.0.windows.1`, and I have already run the command `git config --local core.ignorecase false`, but I still need the `--force` option. If not, I got the `fatal: destination exists` error. – ollydbg23 Jul 09 '23 at 01:15
1654

Git has a configuration setting that tells it whether to expect a case-sensitive or insensitive file system: core.ignorecase. To tell Git to be case-senstive, simply set this setting to false. (Be careful if you have already pushed the files, then you should first move them given the other answers).

git config core.ignorecase false

Note that setting this option to false on a case-insensitive file system is generally a bad idea. Doing so will lead to weird errors. For example, renaming a file in a way that only changes letter case will cause git to report spurious conflicts or create duplicate files(from Mark Amery's comment).

Documentation

From the git config documentation:

core.ignorecase

If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds makefile when git expects Makefile, git will assume it is really the same file, and continue to remember it as Makefile.

The default is false, except git-clone(1) or git-init(1) will probe and set core.ignorecase true if appropriate when the repository is created.

Case-insensitive file-systems

The two most popular operating systems that have case-insensitive file systems that I know of are

  • Windows
  • OS X
sleske
  • 81,358
  • 34
  • 189
  • 227
  • This is a good answer and worked for me, but be careful when doing this because it changes your production environment. So consider this change carefully before making it. – usumoio Jan 09 '14 at 14:53
  • 2
    Turns out this was enabled by default in a project. Sure made life interesting for a bit. – Matthew Setter Mar 26 '14 at 16:20
  • Looks like you have to do it for every git repository you have. How to set it global? – Mateus Viccari Dec 13 '14 at 11:17
  • 19
    On a side note, I don't think that Mac OS X itself is case-insensitive. Instead, it's the filesystem that determines case-sensitivity. When formatting a HFS+ partition, users can choose whether to make it case-sensitive or insensitive. Case case-insensitive is the default. – spaaarky21 Dec 16 '14 at 19:02
  • 328
    It seems very worth noting in this answer that setting this option to `false` on a case-insensitive file system is a *bad idea*. This isn't necessarily obvious. For example, I just tried this on my Mac, thinking it would fix my problems, then renamed a file from `productPageCtrl.js` to `ProductPageCtrl.js`. `git status` saw a *new* file called `ProductPageCtrl.js` but *didn't* think that `productPageCtrl.js` had been deleted. When I added the new files, committed, and pushed to GitHub, the GitHub repo now contained *both* files even though my (supposedly up to date) local repo had only one. – Mark Amery Feb 09 '15 at 10:25
  • 8
    @MarkAmery That sounds a lot like a bug in your Git client. Did you file a report? – Domi Feb 13 '15 at 11:49
  • 1
    This worked perfectly for my situation. I had renamed three classes within Visual Studio, and knew that the name change had taken place in the file system, but didn't notice that the change had not taken place in git until I had created a pull request and the files still had the same missing case issue that they had before. – dmoore1181 Jan 19 '16 at 19:47
  • 43
    @Domi this is not a bug, this is expected behavior. It is in fact a bad idea to set this to false on an insensitive filesystem because this is what happens. The reason why git didn't saw the lower-case file been deleted is that the filesystem doesn't report it as deleted as it *does ignore* the case while git does not with this option set to false. Its not that the filenames don't have lower vs upper case on ntfs or fat its just that filename lookup is ignoring the case. – ohcibi Jun 02 '16 at 17:40
  • @ohcibi From a user perspective, it still feels a lot like an immaturity, since you would hope that your Git client is smart enough to take care of this. But then again, Linux is not known for trying to make things user-friendly, but robust :) – Domi Jun 03 '16 at 03:21
  • 32
    @Domi git *is* smart enough. Thats why you should *not* set this to false on a case insensitive file system. Use `git mv` to move the file and see how git manages it. If you move the file without git, there is *nothing* git can do as the filesystem isn't telling the truth to git. This is an issue of ntfs/fat/hfs and thelike and not git/linux. – ohcibi Jun 03 '16 at 05:06
  • This works on local git repo, but doesn't seem to have effect after pushing – Mathijs Segers Oct 19 '16 at 08:03
  • @Mark Amery I have comfired that `git config core.ignorecase false` is useless on mac.I have to wrap git push/pull/checkout/status with another tool to workaround this git bug. – bronze man Nov 11 '16 at 02:30
  • 2
    @ohcibi this does seem like a bug to me if it behaves this way. It is easy enough to pass the flag `FILE_FLAG_POSIX_SEMANTICS` to the method to verify the file exists using its case sensitive name. The file WON'T be found if this flag is set. Also for find file you can use `FileFirstFileEx` with `FIND_FIRST_EX_CASE_SENSITIVE`. References: https://mathematica.stackexchange.com/questions/97734/case-sensitive-file-names-windowsposix https://msdn.microsoft.com/en-us/library/windows/desktop/aa364419(v=vs.85).aspx – Jeremy Sep 28 '17 at 19:46
  • Worked great for me on Windows 10, GitKraken client. – John Hatton Sep 19 '18 at 14:27
  • 3
    Post should be edited to include various warning mentioned here. I wasted a lot of time because of this. – bluephoton Feb 01 '19 at 06:30
  • 1
    Using case-insensitive fs/os for dealing with case-sensitive filenames is a bug in your workflow. – Dávid Horváth Jun 30 '19 at 17:17
  • Running `$>git config core.ignorecase` will give you the current setting. In my case it was `true`. Hence my file name extension case changes were not getting identified. Running `$> git config core.ignorecase false` has done the trick and worked like a charm. Note that I had to restart the Visual Studio 2017. – Dinesh Halpage Jan 23 '20 at 13:39
  • does the OP mean macOS or OSX? – mesqueeb Aug 28 '20 at 05:32
  • @MarkAmery's comment is from 2015. What he describes (keeping old file) is not happening anymore. – Loolooii Oct 08 '20 at 13:25
  • @Loolooii it's still happening with git 2.29.2 – Nikolai Nov 24 '20 at 11:04
  • 2
    Add the global flag via: `git config --global core.ignorecase false` – Abel Wenning Feb 04 '21 at 19:08
  • Worked on MacOs, however it should be noted that this created duplicate files. – Daniel Lefebvre Apr 22 '21 at 15:56
  • @MarkAmery: Your comment is a valuable warning, I took the liberty of adding it to the answer. – sleske May 12 '21 at 11:04
  • @sleske Hmm. I won't remove it the warning, but on further reflection since I left that comment I think the real problem is that this answer is just fundamentally wrong. This question is all about case-insensitive file systems (since on case-sensitive ones you can handle a case change like any other rename), and since setting `ignorecase` to `false` on a case-insensitive file system breaks stuff and doesn't help at all, it seems to me that this answer is just plain never useful in any circumstances. [1/2] – Mark Amery May 12 '21 at 11:19
  • [2/2] Thus it seems to me that the edited-in warning kind of torpedoes the entire answer - it amounts to a warning saying "by the way, this answer is wrong and you should ignore it". I've got mixed feelings about such warnings. Really, I think what this answer needs is to be heavily downvoted - but, frustratingly, only a small fraction of the over 250 upvoters on my comment pointing out the answer's problems have downvoted the answer. I'm not sure what the best way to proceed is. ¯\\_(ツ)_/¯ – Mark Amery May 12 '21 at 11:21
  • @MarkAmery: Yes, the problem is quite tricky, and it seems there are problems with all possible solutions - case-insensitive FS just suck :-/. Maybe I can think of a better edit later. – sleske May 12 '21 at 11:37
  • 2
    To RENAME/RE-CASE a directory, you should `git mv subjectdirectory tmp` then `git mv tmp SubjectDirectory`. That will avoid the problem that @Mark Amery experienced. – Abel Wenning Feb 23 '22 at 16:59
  • Turning on case sensitivity would be good, if there were not so many bugs in git management tools. At least on Windows. – Hogan Jan 07 '23 at 11:26
  • ! Be careful using this setting in a case insensitive OS. I recommend using this setting only temporarily if you don't remember the files that were renamed. 1) Use `git config core.ignorecase false` 2) Check with `git status` and take a note of the files and folders with a change 3) Set the setting to the previous default value with `git config core.ignorecase true` 4) Use `git mv -f filename FileName` where necessary – Giumex Apr 30 '23 at 17:46
294

Using SourceTree I was able to do this all from the UI

  1. Rename FILE.ext to whatever.ext
  2. Stage that file
  3. Now rename whatever.ext to file.ext
  4. Stage that file again

It's a bit tedious, but if you only need to do it to a few files it's pretty quick

Chris Barr
  • 29,851
  • 23
  • 95
  • 135
  • 5
    The same with git bash – Alex78191 Jun 03 '17 at 17:01
  • 11
    "Stage that file" is the important part - none of the other answers above worked for me. It actually worked with the plain old Windows command prompt. – Vlad Sabev Dec 21 '17 at 16:43
  • 2
    I didn't realize this worked through the staging area. But in my case, I wanted to modify the folder names as well as some files within those folders. So I first renamed all folders to temporary names. Committed the new names (all files within) and the "deleted" files. Git flagged them all as "renamed". Then renamed all those folders back to their new case versions and committed again. Finally, merged those 2 commits. But based on what you wrote, I could have done the whole thing through the sating area directly, without creating 2 commits + merge. – ThermoX Oct 12 '18 at 16:08
  • 4
    Works also with gitkraken on folder name. – Philippe Matray Oct 29 '18 at 09:55
  • If your operating system is case insensitive changes to the filename will not appear in Sourcetree – png Mar 10 '20 at 23:58
  • Old I know, but this one liner should generate all the git commands you need to move the files. Pipe it into bash to actually run them, ie append '| bash', then do your git commit ``` find . -type f -name '*[A-Z]*' | while read a; do echo git mv $a $(dirname $a)/$(basename $a| tr 'A-Z' 'a-z'); done ``` this should do similar for dir names (more dangerous though) ``` find . -depth -type d -name '*[A-Z]*' | while read a; do echo git mv $a $(dirname $a)/$(basename $a| tr 'A-Z' 'a-z'); done ``` – krad Jan 17 '22 at 11:56
  • 2
    This must be the simplest and easiest solution to understand suggested here. For git-noobs (like me) to "Stage" a file means to "add" a file without committing file. – Joel Feb 09 '22 at 09:39
  • A mix of this and `git mv` worked for me. – Gustavo Straube Oct 25 '22 at 19:37
  • If you have a bunch of case changes, even simpler: drag all the icons out into a separate folder, stage the changes, drag them back, stage the changes, and that will pick up the case changes. – Rey Jan 19 '23 at 13:43
269

Fix git filename case on whole repo:

git rm -r --cached .
git add --all .

git status ##Review that **only** changes staged are renames

## Commit your changes after reviewing:
git commit -a -m "Fixing file name casing"
git push origin main

Explanation from @Uriahs Victor comment:

What this command actually does is deletes the cached version of the file/folder names that git thought still existed. So it will clear its cache but leave everything in the current folder (where you've made your changes locally) but it will see that those other wrong case folders/files do not exist anymore so will show them as deleted in git status. Then you can push up to GitHub and it will remove the folders/files with wrong cases. This answer has a graphic depicting what the command means.

Manpreet
  • 91
  • 1
  • 11
andrewvergel
  • 2,791
  • 1
  • 14
  • 5
  • 37
    This is the solution. And unlike the other answers it works well when you are doing batch renames. On glamourphilly.org we needed to change every .Jpg to .jpg. In Finder you can do batch renames like that and this answer lets you check it in. – William Entriken Dec 09 '19 at 22:50
  • 3
    This was the only easy solution for me too – Bálint Juhász Oct 01 '20 at 12:03
  • 1
    This is the easiest solution by far. Works for files and directories. Thanks! – Gaz Sep 28 '21 at 18:50
  • OMG THANK YOUUUU I was ready to pull out my hair as to why i have two cases of the same folders on github even though locally I only had one case! this was frustrating thank you – Uriahs Victor Oct 03 '21 at 22:03
  • 10
    What this command actually does is deletes the cached version of the file/folder names that git thought still existed. So it will clear its cache but leave everything in the current folder (where you've made your changes locally) but it will see that those other wrong case folders/files do not exist anymore so will show them as deleted in `git status`. Then you can push up to github and it will remove the folders/files with wrong cases. This answer has a graphic depicting what the command means: https://stackoverflow.com/a/41863575/4484799 – Uriahs Victor Oct 03 '21 at 22:24
  • POV: The best answer has only 70 upvotes – cody Oct 09 '21 at 22:46
  • 2
    someone give this man a raise! – shoaib30 Apr 18 '22 at 01:16
  • This is the easiest way to handle **case changes in many filenames** in a repository. I had to do this when I changed the case of many names in a large repo after setting `git config core.ignorecase false`. Although the case changes appeared in my local repo, on pushing to GitHub the pre-case-changed files appeared alongside their case-changed twins. These steps fixed the issue on GitHub. – Dave Everitt Jul 19 '22 at 12:05
  • Upvoting so this can gain more reach, this works flawlessly as I recently restructure my code and the inconsistent naming make me have to rename lots of files/dir as to adhere to the style rule. – darkash Nov 28 '22 at 09:39
  • This is AMAZING. Another huge benefit is that it creates a deletion commit for files that have since been `.gitignore`d - cleaning up so much in one pass! – J. Dimeo Mar 10 '23 at 05:04
  • THIS IS IT. `git config core.ignorecase false` ended up duplicating the files on osx, but this is what reset the state & updated the names correctly. – ilike2breakthngs Apr 14 '23 at 04:53
  • Didn't work to me, `git add --all .` return everything back and `git status` says: "nothing to commit, working tree clean". What am I doing wrong? I was forced to `git add` all "ok-sensetive" files by hands, and the do commit with deleted "notok-sensetive" files. – Vlad May 06 '23 at 14:26
  • Doing this even made Sourctree recognize the changes. :-) Awesome! – bbasmer Aug 18 '23 at 12:09
163

This is what I did on OS X:

git mv File file.tmp
git mv file.tmp file

Two steps because otherwise I got a “file exists” error. Perhaps it can be done in one step by adding --cached or such.

Sijmen Mulder
  • 5,767
  • 3
  • 22
  • 33
104

Sometimes it is useful to temporarily change Git's case sensitivity.

Method #1 - Change case sensitivity for a single command:

git -c core.ignorecase=true checkout mybranch to turn off case-sensitivity for a single checkout command. Or more generally: git -c core.ignorecase= <<true or false>> <<command>>. (Credit to VonC for suggesting this in the comments.)

Method #2 - Change case sensitivity for multiple commands:

To change the setting for longer (e.g. if multiple commands need to be run before changing it back):

  1. git config core.ignorecase (this returns the current setting, e.g. false).
  2. git config core.ignorecase <<true or false>> - set the desired new setting.
  3. ...Run multiple other commands...
  4. git config core.ignorecase <<false or true>> - set config value back to its previous setting.
Steve Chambers
  • 37,270
  • 24
  • 156
  • 208
  • 1
    Why not directly `git -c core.ignorecase= checkout <>`? Nothing to reset after. – VonC Jul 10 '18 at 11:28
  • 2
    I had a weird experience of the proposed core.ignorecase working when changing from lowercase to uppercase, but not for uppercase to lowercase. seems the only reliable solution is to stop using an OS which fails to recognise filename case. – CodingMatters Sep 30 '18 at 02:56
  • Is there a reason why it should be a temporary change? Would that cause any problem if I just leave the settings changed to case sensitive? – cytsunny Jan 24 '19 at 09:39
  • This may depend on a few factors, in particular whether the target file system is case sensitive - see https://en.wikipedia.org/wiki/Case_sensitivity#In_filesystems. The temporary change may be needed if the deployment file system has different case sensitivity to the file system used for development. _Also in my case I work in a team where everyone is expected to have the same Git settings (i.e. case sensitive) so if I turn it off it needs to be temporary._ – Steve Chambers Jan 24 '19 at 09:49
51

We can use git mv command. Example below , if we renamed file abcDEF.js to abcdef.js then we can run the following command from terminal

git mv -f .\abcDEF.js  .\abcdef.js
  • 3
    Forcing is not needed anymore since git v2.0.1 (@see https://github.com/git/git/commit/baa37bff9a845471754d3f47957d58a6ccc30058 ) – Julian Hofmann Jun 18 '20 at 14:05
45

Under OSX, to avoid this issue and avoid other problems with developing on a case-insensitive filesystem, you can use Disk Utility to create a case sensitive virtual drive / disk image.

Run disk utility, create new disk image, and use the following settings (or change as you like, but keep it case sensitive):

Mac Disk Utility Screenshot

Make sure to tell git it is now on a case sensitive FS:

git config core.ignorecase false
user1821510
  • 665
  • 5
  • 6
  • 15
    Nah, nuclear is running a fully case-sensitive boot drive on OSX. You'll have to live without poorly written (ahem, Adobe) apps, or run those in their own case-stupid VM, but it's worth it if you code primarily for *nix systems. – Mike Marcacci Aug 06 '15 at 01:33
  • 1
    This is the only option that properly works. I've tried the rest and you end up in a pickle one way or another. Solve the problem properly by doing this. – John Hunt Jun 03 '16 at 09:12
  • 2
    Note that Disk Utility has a bug OS X 10.11 -- It won't create case sensitive images. You need to use the command line tool hdiutil. http://apple.stackexchange.com/questions/217915/how-to-create-a-case-sensitive-filesystem-in-10-11-1 – dellsala Jan 18 '17 at 20:51
  • 7
    With APFS in High Sierra this is even easier. Click the icon of a drive with a plus and add a case-sensitive volume with no limits on size. It just shares space with the main volume and mounts at /Volumes/volume-name. – Michael Fox Aug 30 '17 at 13:02
31
  1. rename file Name.jpg to name1.jpg

  2. commit removed file Name.jpg

  3. rename file name1.jpg to name.jpg

  4. amend added file name.jpg to previous commit

    git add name.jpg
    git commit --amend
    
Mark Amery
  • 143,130
  • 81
  • 406
  • 459
razon
  • 3,882
  • 2
  • 33
  • 46
  • 2
    I am getting this `fatal: bad source, source=name1.jpg, destination=name.jpg` at step 3. Do you have suggestion? Thx – Anthony Kong Mar 30 '17 at 00:48
  • 3
    You can not do a commit, just `git add`. – Alex78191 Jun 03 '17 at 17:00
  • Worked for me. Honestly, its actually correct from an audit point of view. – BeaverProj Jan 14 '21 at 18:16
  • 1
    As [CBarr's answer](https://stackoverflow.com/a/40307511/1709587) notes, you don't need the intermediate commit here. You can just rename, stage, rename, stage, then commit, without the extra commit in the middle that this answer uses. – Mark Amery May 03 '21 at 16:04
29

Similar to @Sijmen's answer, this is what worked for me on OSX when renaming a directory (inspired by this answer from another post):

git mv CSS CSS2
git mv CSS2 css

Simply doing git mv CSS css gave the invalid argument error: fatal: renaming '/static/CSS' failed: Invalid argument perhaps because OSX's file system is case insensitive

p.s BTW if you are using Django, collectstatic also wouldn't recognize the case difference and you'd have to do the above, manually, in the static root directory as well

Anupam
  • 14,950
  • 19
  • 67
  • 94
23

I tried the following solutions from the other answers and they didn't work:

If your repository is hosted remotely (GitHub, GitLab, BitBucket), you can rename the file on origin (GitHub.com) and force the file rename in a top-down manner.

The instructions below pertain to GitHub, however the general idea behind them should apply to any remote repository-hosting platform. Keep in mind the type of file you're attempting to rename matters, that is, whether it's a file type that GitHub deems as editable (code, text, etc) or uneditable (image, binary, etc) within the browser.

  1. Visit GitHub.com
  2. Navigate to your repository on GitHub.com and select the branch you're working in
  3. Using the site's file navigation tool, navigate to the file you intend to rename
  4. Does GitHub allow you to edit the file within the browser?
    • a.) Editable
      1. Click the "Edit this file" icon (it looks like a pencil)
      2. Change the filename in the filename text input
    • b.) Uneditable
      1. Open the "Download" button in a new tab and save the file to your computer
      2. Rename the downloaded file
      3. In the previous tab on GitHub.com, click the "Delete this file" icon (it looks like a trashcan)
      4. Ensure the "Commit directly to the branchname branch" radio button is selected and click the "Commit changes" button
      5. Within the same directory on GitHub.com, click the "Upload files" button
      6. Upload the renamed file from your computer
  5. Ensure the "Commit directly to the branchname branch" radio button is selected and click the "Commit changes" button
  6. Locally, checkout/fetch/pull the branch
  7. Done
user110857
  • 2,023
  • 1
  • 21
  • 33
  • I renamed directly on BitBucket and it worked. Thanks. – rsc Dec 24 '17 at 00:21
  • Good to know. This technique should theoretically work on any repository hosting platform but I'd be interested to know if there are any that it would not work with. – user110857 Jan 02 '18 at 19:11
  • Doesn't work for files that can't be edited in the browser, like images or PDF; there is no edit option, obviously. – Abhijit Sarkar Dec 26 '18 at 20:16
  • @AbhijitSarkar Good point. I updated my answer for those cases. I tested and verified these instructions work. – user110857 Jan 11 '19 at 20:36
20

With the following command:

git config --global  core.ignorecase false

You can globally config your git system to be case sensitive for file and folder names.

AmerllicA
  • 29,059
  • 15
  • 130
  • 154
11

Mac OSX High Sierra 10.13 fixes this somewhat. Just make a virtual APFS partition for your git projects, by default it has no size limit and takes no space.

  1. In Disk Utility, click the + button while the Container disk is selected
  2. Select APFS (Case-Sensitive) under format
  3. Name it Sensitive
  4. Profit
  5. Optional: Make a folder in Sensitive called git and ln -s /Volumes/Sensitive/git /Users/johndoe/git

Your drive will be in /Volumes/Sensitive/

enter image description here

How do I commit case-sensitive only filename changes in Git?

Ray Foss
  • 3,649
  • 3
  • 30
  • 31
  • I love this suggestion, it elegantly and painlessly solves the problem without resort to ugly workarounds. Thanks! – Phil Gleghorn Sep 24 '18 at 23:42
  • Just an advise, do not do that, Changing Hard format to `APFS (Case-sensitive)` makes your system very slow and you will face many weird issue, I faced ReactNative build issue, some addresses could not be found. so it's better to have `APFS` the default of the company. for **git** case it's better to use [this solution](https://stackoverflow.com/a/69626114/6877799). – AmerllicA Jun 01 '22 at 09:29
  • @AmerllicA This doesn't change your system hard drive, only a partition to Case Sensitive. Performance is actually slightly better with case-senstivity on. The solution you linked to does not work for everyone as code that assumes linux-like case senstivity may not run, such as when two files are the same name but different case. – Ray Foss Jun 03 '22 at 22:36
7

so there are many solutions to this case sensitivity deployment problem with how GitHub handles it.

In my case, I had changed the filename casing convention from uppercase to lowercase.

I do believe that git can track the change but this command git config core.ignorecase false dictates how git operates behind the scenes

In my case, I ran the command and git suddenly had lots of files to track labeled untracked.

I then hit git add. , then git committed and ran my build on netlify one more time.

Then all errors now displayed could be traced e.g Module not found: Can't resolve './Components/ProductRightSide' in '/opt/build/repo/components/products and fixed such that git was able to track and implement the changes successfully.

It's quite a workaround and a fingernail away from frustration but trust me this will surely work.

PS: after fixing your issue you may want to run the command git config core.ignorecase true to restore how git works with case sensitivity.

Also, note git config core.ignorecase false has issues with other filename extensions so you may want to watch out, do it if you know what you’re doing and are sure of it.

Here's a thread on netlify that can help out, possibly

Think Digital
  • 129
  • 1
  • 7
  • This is good but it seems to make the files as new, loosing all history rather than simply renaming the existing file with all of it's changes. – Craig.C Jul 04 '22 at 22:15
5

Years later I need to come back to my own question and provide yet another possible solution! I ran into this issue on a project where only a single file needed to be renamed. This is what I did and it worked for me.

git mv -f src/MyFile.js src/myfile.js

Which I learned both from this thread and this answer

Chris Barr
  • 29,851
  • 23
  • 95
  • 135
4

When you've done a lot of file renaming and some of it are just a change of casing, it's hard to remember which is which. manually "git moving" the file can be quite some work. So what I would do during my filename change tasks are:

  1. remove all non-git files and folder to a different folder/repository.
  2. commit current empty git folder (this will show as all files deleted.)
  3. add all the files back into the original git folder/repository.
  4. commit current non-empty git folder.

This will fix all the case issues without trying to figure out which files or folders you renamed.

  • 1
    Why not `git commmit --amend` in In paragraph 4? Otherwise, there will be an extra commit with the removal of all files. Or you can use `git rebase -i` with squash. – Alex78191 Jun 03 '17 at 17:06
3

I've faced this issue several times on MacOS. Git is case sensitive but Mac is only case preserving.

Someone commit a file: Foobar.java and after a few days decides to rename it to FooBar.java. When you pull the latest code it fails with The following untracked working tree files would be overwritten by checkout...

The only reliable way that I've seen that fixes this is:

  1. git rm Foobar.java
  2. Commit it with a message that you cannot miss git commit -m 'TEMP COMMIT!!'
  3. Pull
  4. This will pop up a conflict forcing you to merge the conflict - because your change deleted it, but the other change renamed (hence the problem) it
    1. Accept your change which is the 'deletion'
    2. git rebase --continue
  5. Now drop your workaround git rebase -i HEAD~2 and drop the TEMP COMMIT!!
  6. Confirm that the file is now called FooBar.java
Ashwin Jayaprakash
  • 2,168
  • 24
  • 29
  • -1. I can't repro the error you mention here, and without it the rest of the answer doesn't make sense. Also, doing `git rebase --continue` without a rebase in progress just yields a *"No rebase in progress?"* error, and there's no rebase in progress during step 4.2, so running that command there doesn't make sense either. – Mark Amery May 03 '21 at 15:59
2

I took @FiniteLooper answer and wrote a Python 3 Script to do it with a list of files:

#!/usr/bin/env python3
# -*- coding: UTF-8 -*-

import os
import shlex
import subprocess

def run_command(absolute_path, command_name):
    print( "Running", command_name, absolute_path )

    command = shlex.split( command_name )
    command_line_interface = subprocess.Popen( 
          command, stdout=subprocess.PIPE, cwd=absolute_path )

    output = command_line_interface.communicate()[0]
    print( output )

    if command_line_interface.returncode != 0:
        raise RuntimeError( "A process exited with the error '%s'..." % ( 
              command_line_interface.returncode ) )

def main():
    FILENAMES_MAPPING = \
    [
        (r"F:\\SublimeText\\Data", r"README.MD", r"README.md"),
        (r"F:\\SublimeText\\Data\\Packages\\Alignment", r"readme.md", r"README.md"),
        (r"F:\\SublimeText\\Data\\Packages\\AmxxEditor", r"README.MD", r"README.md"),
    ]

    for absolute_path, oldname, newname in FILENAMES_MAPPING:
        run_command( absolute_path, "git mv '%s' '%s1'" % ( oldname, newname ) )
        run_command( absolute_path, "git add '%s1'" % ( newname ) )
        run_command( absolute_path, 
             "git commit -m 'Normalized the \'%s\' with case-sensitive name'" % (
              newname ) )

        run_command( absolute_path, "git mv '%s1' '%s'" % ( newname, newname ) )
        run_command( absolute_path, "git add '%s'" % ( newname ) )
        run_command( absolute_path, "git commit --amend --no-edit" )

if __name__ == "__main__":
    main()
Chris Barr
  • 29,851
  • 23
  • 95
  • 135
Evandro Coan
  • 8,560
  • 11
  • 83
  • 144
2

Or simply rename the required file over git repository web UI interface and commit :)

Petr Šebesta
  • 201
  • 2
  • 5
1

If nothing worked use git rm filename to delete file from disk and add it back.

0

I made a bash script to lowercase repository file names for me:

function git-lowercase-file {
  tmp="tmp-$RANDOM-$1"
  git mv -f $1 $tmp
  git mv -f $tmp ${1,,}
}

then you can use it like this:

git-lowercase-file Name.jpg
Community
  • 1
  • 1
Kodie Grantham
  • 1,963
  • 2
  • 17
  • 27
-1

If you're doing more complex change, like directory name casing change, you can make that change from a Linux machine, because Linux itself (as well as git on Linux) treats files/directories with same names but different casing as completely different files/directories.

So if you're on Windows, you can install Ubuntu using WSL, clone your repo there, open the cloned repo directory using VSCode (use WSL remote extension to access WSL Ubuntu from Windows), then you will be able to make your renames through VSCode and commit/push them using VSCode git integration.

victorm1710
  • 1,263
  • 14
  • 11