How do I commit case-sensitive only filename changes in Git?
Solution 1
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.)
Solution 2
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 expectsMakefile
, git will assume it is really the same file, and continue to remember it asMakefile
.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
Solution 3
Using SourceTree I was able to do this all from the UI
-
Rename
FILE.ext
towhatever.ext
- Stage that file
- Now rename
whatever.ext
tofile.ext
- 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
Solution 4
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.
Solution 5
I used those following steps:
git rm -r --cached .
git add --all .
git commit -a -m "Versioning untracked files"
git push origin master
For me is a simple solution
Gil Shulman
Updated on July 08, 2022Comments
-
Gil Shulman almost 2 years
I have changed a few files name by de-capitalize the first letter, as in
Name.jpg
toname.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.-
Admin almost 11 years@nif this isn't quite correct, Git actually has a configuration setting that controls whether or not it ignores case sensitivity.
-
VonC about 9 yearsSee stackoverflow.com/a/24979063/6309: since git 2.0.1, a simple
git mv
works. -
KyleMit over 8 yearspossible duplicate of Git: Changing capitalization of filenames
-
Per Lundberg about 7 years@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...
-
-
usumoio over 10 yearsThis 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.
-
Matthew Setter about 10 yearsTurns out this was enabled by default in a project. Sure made life interesting for a bit.
-
WiseStrawberry almost 10 yearsthis gives me 'source directory is empty' while it is not
-
Mateus Viccari over 9 yearsLooks like you have to do it for every git repository you have. How to set it global?
-
spaaarky21 over 9 yearsOn 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.
-
Mark Amery about 9 yearsIt 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 fromproductPageCtrl.js
toProductPageCtrl.js
.git status
saw a new file calledProductPageCtrl.js
but didn't think thatproductPageCtrl.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. -
Domi about 9 years@MarkAmery That sounds a lot like a bug in your Git client. Did you file a report?
-
rperryng almost 9 yearsas the top answer suggests,
-f
(force) is the flag you are looking for -
Mike Marcacci over 8 yearsNah, 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.
-
dmoore1181 over 8 yearsThis 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.
-
ohcibi almost 8 years@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.
-
Domi almost 8 years@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 :)
-
ohcibi almost 8 years@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. -
John Hunt almost 8 yearsThis 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.
-
HEKTO over 7 yearsTried that and got
fatal: renaming '...' failed: File exists
. I'm doing that in Ubuntu virtual machine, which runs in OSX -
HEKTO over 7 years@rperryng - no, the
-f
flag doesn't help in case the underlying FS is case-insensitive. However, two-step solution worked for me -
Mathijs Segers over 7 yearsThis works on local git repo, but doesn't seem to have effect after pushing
-
bronze man over 7 years@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. -
caesarsol over 7 yearsUsing a case-insensitive FS (on Mac) and
-f
worked! Thanks for the tip -
caesarsol over 7 yearsUsing MacOS here (case-insensitive FS) and -f worked! Thanks for the tip
-
dellsala over 7 yearsNote 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. apple.stackexchange.com/questions/217915/…
-
StoriKnow about 7 years@WiseStrawberry if you have spaces in the file path, trying wrapping it in quotes.
-
Anthony Kong about 7 yearsI am getting this
fatal: bad source, source=name1.jpg, destination=name.jpg
at step 3. Do you have suggestion? Thx -
Alex78191 almost 7 yearsYou can not do a commit, just
git add
. -
Alex78191 almost 7 yearsThe same with git bash
-
Alex78191 almost 7 yearsWhy not
git commmit --amend
in In paragraph 4? Otherwise, there will be an extra commit with the removal of all files. Or you can usegit rebase -i
with squash. -
rickrizzo over 6 yearsDon't forget to give the full file path. Obvious, I know, but got me for a while
-
Stevoisiak over 6 yearsAs 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)
-
Michael Fox over 6 yearsWith 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.
-
Jeremy over 6 years@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 useFileFirstFileEx
withFIND_FIRST_EX_CASE_SENSITIVE
. References: mathematica.stackexchange.com/questions/97734/… msdn.microsoft.com/en-us/library/windows/desktop/… -
nich over 6 yearsThis also worked with a folder on windows without the
-f
flag. -
nietonfir over 6 years
git -c "core.ignorecase=false" add .
will consider files whose case has been changed for commit. -
Vlad Sabev over 6 years"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.
-
rsc over 6 yearsI renamed directly on BitBucket and it worked. Thanks.
-
user110857 over 6 yearsGood 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.
-
Damon about 6 yearsThis isn't working for me on a directory i want to rename (
failed: Invalid argument
) with full file path and without. weird. -
VonC almost 6 yearsWhy not directly
git -c core.ignorecase=<true or false> checkout <<branch>>
? Nothing to reset after. -
Sam Soffes over 5 yearsYou 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. -
John Hatton over 5 yearsWorked great for me on Windows 10, GitKraken client.
-
Phil Gleghorn over 5 yearsI love this suggestion, it elegantly and painlessly solves the problem without resort to ugly workarounds. Thanks!
-
CodingMatters over 5 yearsI 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.
-
jeromej over 5 yearsLooks very hacky, isn't it? Or monkey-patching.
-
ThermoX over 5 yearsI 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.
-
Philippe Matray over 5 yearsWorks also with gitkraken on folder name.
-
Patrick over 5 yearsStrangely 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.
-
Abhijit Sarkar over 5 yearsDoesn't work for files that can't be edited in the browser, like images or PDF; there is no edit option, obviously.
-
user110857 over 5 years@AbhijitSarkar Good point. I updated my answer for those cases. I tested and verified these instructions work.
-
cytsunny over 5 yearsIs 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?
-
Steve Chambers over 5 yearsThis may depend on a few factors, in particular whether the target file system is case sensitive - see 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.
-
bluephoton about 5 yearsPost should be edited to include various warning mentioned here. I wasted a lot of time because of this.
-
DeepSpace101 about 5 yearsTo the top voted comment: you do need the
-f
switch with the latest git (2.18) otherwise you could get thefatal: destination exists
error. -
Dávid Horváth almost 5 yearsUsing case-insensitive fs/os for dealing with case-sensitive filenames is a bug in your workflow.
-
William Entriken over 4 yearsThis 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.
-
Brian Peterson over 4 yearsgit mv -f {O,o}ldFileNameCase
-
Dinesh Halpage over 4 yearsRunning
$>git config core.ignorecase
will give you the current setting. In my case it wastrue
. 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. -
png about 4 yearsIf your operating system is case insensitive changes to the filename will not appear in Sourcetree
-
Amy Pellegrini about 4 yearsIf I do this I can see the file has been removed from Git but it doesn't track the new file.
-
Liran H almost 4 yearsWorked perfectly on Mac OS Catalina with git 2.24.0
-
Julian Hofmann almost 4 yearsForcing is not needed anymore since git v2.0.1 (@see github.com/git/git/commit/… )
-
mesqueeb over 3 yearsdoes the OP mean macOS or OSX?
-
Bálint Juhász over 3 yearsThis was the only easy solution for me too
-
Loolooii over 3 years@MarkAmery's comment is from 2015. What he describes (keeping old file) is not happening anymore.
-
Sebastiaan over 3 yearsIt'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. -
Nikolai over 3 years@Loolooii it's still happening with git 2.29.2
-
BeaverProj over 3 yearsWorked for me. Honestly, its actually correct from an audit point of view.
-
Abel Wenning about 3 yearsAdd the global flag via:
git config --global core.ignorecase false
-
Daniel Lefebvre about 3 yearsWorked on MacOs, however it should be noted that this created duplicate files.
-
Mark Amery almost 3 years-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 almost 3 yearsAs CBarr's answer 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.
-
sleske almost 3 years@MarkAmery: Your comment is a valuable warning, I took the liberty of adding it to the answer.
-
Mark Amery almost 3 years@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
tofalse
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 almost 3 years[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. ¯\_(ツ)_/¯
-
sleske almost 3 years@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.
-
Matthew Joughin over 2 yearsFYI: I am on git 2.29.2, running on macOS, and it still requires the -f to do a case sensitive file rename
-
Gaz over 2 yearsThis is the easiest solution by far. Works for files and directories. Thanks!
-
Uriahs Victor over 2 yearsOMG 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 over 2 yearsTry this answer if you ever come across this again stackoverflow.com/a/55541435/4484799
-
Uriahs Victor over 2 yearsWhat 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: stackoverflow.com/a/41863575/4484799 -
cody over 2 yearsPOV: The best answer has only 70 upvotes
-
Aaron Franke over 2 yearsThis 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).
-
Dale Ryan over 2 yearsMAGNIFICENT! Saves time
-
krad over 2 yearsOld 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 ```
-
Joel about 2 yearsThis 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.
-
Abel Wenning about 2 yearsTo RENAME/RE-CASE a directory, you should
git mv subjectdirectory tmp
thengit mv tmp SubjectDirectory
. That will avoid the problem that @Mark Amery experienced. -
Mr Patience about 2 yearsBasically the simplest solution with VS :)
-
shoaib30 about 2 yearssomeone give this man a raise!
-
AmerllicA almost 2 yearsJust 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 haveAPFS
the default of the company. for git case it's better to use this solution. -
Ray Foss almost 2 years@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.
-
KeitelDOG almost 2 yearsSome issue are like Eternal Pandemic. They affect the world for ever, lol. Worked for me on moving a
Signin.js
toSignIn.js
. -
Craig.C almost 2 yearsThis 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.