I want to rename a directory versioned by Git on a Windows system (change the case of the directory name):
$ git mv docs DOCS
Rename from 'docs' to 'DOCS/docs' failed. Should I try again? (y/n) n
fatal: renaming 'docs' failed: Permission denied
I've also tried with the force-option - but with the same result:
$ git mv --force docs DOCS
Rename from 'docs' to 'DOCS/docs' failed. Should I try again? (y/n) n
fatal: renaming 'docs' failed: Permission denied
For some reason Git fails because it thinks DOCS already is an existing directory and the directory should be moved inside it. I know that I can rename & commit using a temporary directory name and then rename & amend-commit to the final name, but isn't there a way to tell Git that I don't want to move inside any other directory?
You can try to do it in 2 step.
$ git mv docs DOCS2
$ git mv DOCS2 DOCS
it will work
I have tried to rename my directory with TortoiseGit using rename, command prompt using git mv, and git bash using git mv. The move command was either mv Status status or git mv Status status2 and both of them respond "failed: Permission denied". So it seems I am either going to have to delete the git repository and create a new one with the new directory name structure or I am going to have to create a Linux VM, clone it down, and try to rename name it there. It seems only files can be renamed under windows, but directories just fail. As for people that say git mv works for them, there has to be something missing in your setup.
Since windows iד case sensitive you cant rename the file to the same letters. (Docs == docs [ignored case])
You can do it from git bash since git bash is cygwin and its case sensitive since its a unix emulator.
The command is git mv
git mv <old name> <new name>
Here is a demo from git bash. (windows 7)
No. There isn't a way to tell Git that you don't want to move the folder inside any other directory.
This is not a limitation of git, but rather a limitation of Windows and NTFS. Because the filesystem is case-insensitive, it reports that the case-changed new name already exists, which causes the behaviour that you encounter. Try a 2 step rename (with a temporary name), then commit, or changing it on a non-windows (technically on a case-sensitive filesytem) computer.
Related
I am new to Unix commands and would like to have some help regarding it.
I am want to practice commands on my Windows Machine. I have installed GitBash and I am trying to execute commands on it. But every time I press enter I get this issue:
$ git init
C:/Users/.git: Permission denied
lenovo#LAPTOP-7Q4QK8A7 MINGW64 /c/Users
$ git clone https://github.com/06-glitch/Rainbow/commit/32c6e7cc3c37d20ff368a2095c34522da297b174
fatal: could not create work tree dir '32c6e7cc3c37d20ff368a2095c34522da297b174': Permission denied
Could anyone please help me with this?
Problem:Your are trying to clone in the users folder which is not accessible.
Answer:Change your directory to the Desktop or any other folder and use the git commands
cd means "change directory"
Use the below code to change directory to root:
cd ~
or In my case my desktop name Aakarsh Teja so.. try cd to that name Remember you have to use quotes if your folder name consists of a SPACE.
cd "Aakarsh Teja"/Desktop
Now you can use your commands for git.
Make sure your git bash is in your destination folder.
Aakarsh Teja#MINGW64 ~/Desktop
$git clone <gitlink>
I use git on windows. In my project I changed case of filename. After that checkout of previous commits failed (commands are in Git Bash):
mkdir repofolder
cd repofolder
git init # create empty repo
git config core.ignorecase false # turn on case-dependent filenames
# create 'readme.txt'
$ echo "blahblahblah" > readme.txt
$ git add readme.txt
$ git commit -m "+readme.txt"
# rename it to 'README.txt'
$ git mv -f readme.txt README.txt
$ git commit -m "readme.txt => README.txt"
$ git status
On branch master
nothing to commit, working directory clean
$ git checkout HEAD~1
error: The following untracked working tree files would be overwritten by checkout:
readme.txt
Please move or remove them before you can switch branches.
Aborting
Why git doesn't allow to checkout previos commits?
You face with the same problem when delete one file and append another one with the same name, but different case. No matter how many commits you do: one (removing and appending in the same commit) or two commits (in first commit you remove file, in second you add another one).
On Windows git can't handle files with the same name but in different case properly
Git on Windows can't handle it because Windows itself can't handle it (emphasis mine):
As part of the requirements for POSIX compliance, the Windows NT File System (NTFS) provides a case-sensitive file and directory naming convention. Even though NTFS and the POSIX subsystem each handle case-sensitivity well, 16-bit Windows-based, MS-DOS-based, OS/2-based, and Win32-based applications do not.
In truth, Windows does have some level of support for NTFS case-sensitivity, but it's pretty flaky:
However, if you attempt to open one of these files in a Win32 application, such as Notepad, you would only have access to one of the files, regardless of the case of the filename you type in the Open File dialog box.
Other inconsistencies also exist. The Windows NT Command Prompt and File Manager correctly display the names of the files. However, normal commands, such as COPY, fail when you attempt to access one or more filenames that differ only in case.
I recent installed Git and I'm trying to update a file using this command:
(On windows 7)
git add Probe.txt
But it says "fatal: pathspec 'probe' did not match any files"
I'm in the directory which the file is. In fact, if I try git status I get "modified: Probe.txt".
How should I update my file?
try git add . which will add everything. Not sure why the specific filename isn't working, but this definitely should.
Looks like you're actually entering a space after "Probe" for some reason, observe:
~% cd /tmp
/tmp% mkdir foo
/tmp% cd foo
foo% git init
Initialized empty Git repository in /tmp/foo/.git/
foo% git add probe .txt
fatal: pathspec 'probe' did not match any files
foo%
I'm not on Windows at the moment but I think you can get the idea.
If you're pretty sure it's not the case, please re-try your command after setting
set GIT_TRACE=1
and update your question by the output of git add Probe.txt so we could guess further.
I wanted to rename a folder from "Frameworks" to "frameworks", but git would not let me add the new lowercase name. I guess it treats filenames case insensitive, does it?
A git add frameworks/ -f didn't help
You can try:
"git mv -f foo.txt Foo.txt" (note: this is no longer needed since git 2.0.1)
to set ignorecase to false in the config file.
But the issue of case (on Windows for instance) is described in the msysgit issue 228 (again: this should now -- June 2014 -- work with git 2.0.1)
there is always an option to set ignorecase to false in the config file that will force Unix like Git semantics on top of NTFS.
Git supports this behavior but it is not the default - from NTFS point of view a.txt
and A.txt are the same thing - so Git tries to preserve that as most users would expect
As a better workaround, you can
git mv foo.txt foo.txt.tmp && git mv foo.txt.tmp Foo.txt
, which also changes the case of the file as stored on disk.
This blog post illustrates the same issue on MacOs during a rebase:
The default on Mac OS X file systems is that they are case-insensitive. FFFFFF.gif is the same as ffffff.gif.
If you delete the file in question, just from the file system, not from the Git index, mind you, you can merge the branch in question, and have it restore the file as if nothing happened.
The steps are pretty simple:
$ rm file/in/question.gif
$ git merge trunk
Anyhow, remember what git mv stands for:
mv oldname newname
git add newname
git rm oldname
, so if newname and oldname clash, you need to make them different (even if it is only for a short period of time), hence the git mv foo.txt foo.txt.tmp && git mv foo.txt.tmp Foo.txt
If you happen to host on Github, you can use the rename function on their website. Had to change the casing for 5 files and found it worked really well.
I was having a similar problem and couldn't get a new folder name (different case) to change on remote repos. I found that the easiest solution was just to move the file out of the repo and commit. Triggering a delete action. Then re-add and when I added, it came in with the proper case.
I have been using git on windows-msysgit. Whenever I try to remove a repository completely either using explorer or using
$ git rm -rf ptp/
fatal: Not a git repository (or any of the parent directories): .git
it errors out "The data present in the reparse point buffer is invalid" or the fatal error above.
What's wrong with me/git?
Thanks in advance
To remove a git repo, just do rm -rf ptp/. That's it.
git rm is used to move items from the index [the staging area for changes / new files], not to delete git repositories.
To get rid of the git repository on Windows do this:
Win+R, Type cmd, Enter.
> cd c:/path/to/parent/of/ptp-repo
> rmdir /S /Q ptp
Or if it fails then check who locks the directory and delete it by hands from Explore.
Most likely some process holds a lock on files/dirs in your repo.
I tried to remove GIT on my windows-XP, by means of the Windows/Configuration/Software menu. After some error message (which I cannot remember), it removed all files. I checked it, and there are no files with ptp in the name left on the entire system.
A problem remained however: each time I opened windows-explorer, a nasty error message came calling for a dll file that wasn't there anymore.
When checking the registry, there were many traces to GIT left in the registry. I removed them carefully by hand, which seems to have solved the problem. This is of course a dangerous path, but I had no choice. Perhaps it is a good idea to look into the Windows-deinstallation script very carefully.
Stef Joosten
On Windows 10, try running cygwin console as admin and rm -rf the dir.
I have also just experienced this odd problem on windows 10: An empty .git folder simply would not delete and a restart of windows did not remedy it, nor did rmdir .git, nor did rm -rf .git.
Similarly to another suggestion, I used ubuntu (instead of cygwin) for windows (https://tutorials.ubuntu.com/tutorial/tutorial-ubuntu-on-windows#0) and issued an rm -rf .git, that worked perfectly
This solution should make it possible to delete any locked files and folders without installing any new programs:
Go to your Resource Monitor (in the Task Manager)
Go to the CPU tab
Search for your file in the "Associated Handles"
Now you'll see which process(es) are locking your file (it's likely explorer.exe)
Close those processes (be careful, this might delete unsaved work)
Delete your previously locked files, this should work without a problem now.
Optional: Start processes again (for explorer.exe: Go to Task Manager, File → New task → type in "explorer.exe")
This should work:
On Git Bash do:
$ git remote remove <name>
To see your remote list:
$ git remote
When I want to remove a GIT repo on Windows... i very simply delete (or move) the .git directory where the repo sits... I do this straight from Explorer... it hasn't failed me yet!
I have a third partition, on a dual boot with Windows 7 and Fedora Linux, and I realized I had a file open in vim in a terminal, and that was causing a .fuse_hidden... file to not be deletable.
When I closed the file in vim, I was able to delete the .git directory.