I am using Git for Windows 2.5.1 under Windows 7 x64.
I am experiencing a strange phenomenon, that is...
...whenever I use Right-Click / Git Bash Here... on a plain directory that is not under the control of git (i.e. there is no .git directory present), a new subdirectory .git gets automatically created (with a file "config" in it), however, no git command has been issued.
I went into my registry settings and I found that the "Git Bash Here..." shortcut translates into "git-bash.exe" "--cd %v".
My question is as follows: is there any way to tell "git-bash.exe" * NOT * to create any .git folder (at least not as long as no git command is issued)
The problem is that I use "Git Bash Here..." all over the place, even for directories that are not under the control of git, and what happens is that my harddisk is now littered with many empty, useless .git directories.
I was thinking, maybe there is an additional option to prevent the creation of .git/config ?
Maybe git-bash.exe --cd %v --do-not-create-git-config ?
Any ideas ?
Thanks for #poke's comment
In fact, in my ".bashrc" I had a left-over from last week's testing: "git config color.diff auto"
I had forgotten to remove that line.
When I remove the "git config color.diff auto", everything goes back to normal
Problem solved
Related
I recently updated Git to version 2.7.2.windows.1 (I am running Windows 7 64-bit). Since the update, I have been unable to run git add with the -p option on files within a certain directory (or its subdirectories) whose name is _ (an underscore).
git status correctly reports that my file has changes:
PS C:\Users\Carl\www\dl> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: _/php/class.Menu.php
And I can add the entire file with a simple git add, or by specifying the file by name. But if I try to include the -p or --patch option (both variations produce the same results), Git reports that there are no changes:
PS C:\Users\Carl\www\dl> git add -p .\_\php\class.Menu.php
No changes.
This only happens for files within the _ directory, but it doesn't matter whether I cd into that directory to run the git add command without having to explicitly specify a path with an underscore in it; it still doesn't work:
PS C:\Users\Carl\www\dl\_\php> git add -p .\class.Menu.php
No changes.
I had initially thought this problem was related to a similar one I encountered recently on files within the _ directory, which I asked about here. However, that problem appears to have been related to Posix path conversion in MinGW, whereas this problem occurs whether I use Git Bash, Windows PowerShell, or cmd.exe.
As I said in that previous question, I believe underscores to be valid in file/directory names. Additionally, I am not the owner of the project so I cannot rename the directory or move the file.
Is this a bug in Git? Are there any additional steps I can take to determine what the underlying issue is?
Well, I was able to reproduce this, and seems that it is the same POSIX-to-Windows path conversion. ProcessMonitor shows that git (actually, perl run by git) looks for a file C:\Program Files\Git\php\class.Menu.php.
To work this around (at least, that worked for me), according to documentation, you can set the environment variable MSYS_NO_PATHCONV temporarily, like so (in git bash):
MSYS_NO_PATHCONV=1 git add -p _/php/class.Menu.php
(I don't know how to set env variables in windows' cmd/powershell, but that should be possible, too.)
You shouldn't enable MSYS_NO_PATHCONV globally/permanently (e.g. using export in git bash or modifying windows' user/system environment variables in system settings), because that can lead to unwanted effects, and it'll probably break much more things than it'll fix (see this SO comment). Actually, git-windows folks warn against even temporary enabling MSYS_NO_PATHCONV.
Having said that, I'm starting to think that OP's problem is a git-for-windows bug and should be reported as such (might have something to do with the fact that git-add is a binary, but git-add--interactive is a perl script).
Another listed workaround is to double the first slash, like git add -p _//php/class.Menu.php (or does that mean the parameter must start with a double slash?), but that doesn't seem to work due to complex intermediate path conversions, that happen between the invocation of git add and the real file access.
I'd try without that .. Also I've never passed a filename to git add -p. I just make my change and run that as is. I would also check to make sure any changes you're making are in fact being applied to that specific file, and the file is being touched.
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'm using git on windows with the git bash and every time I want to autocomplete a filename in a git command I get fatal: Not a git repository: '.git' posted between my already typed characters and the completed ones.
It looks like this:
$ git diff a
<using tab>
$ git diff afatal: Not a git repository: '.git'
pp.js
I can still make the command properly by just pressing enter as expected. But it really starts to get on my nerves.
Any suggestions?
The problem was an extra .git-folder in my src folder. The repository was initialized on the folder above (src/..) and this seemed to mess with git. After the removal of the extra .git folder the problem disappered.
I just discoverd the solution. I had an extra .git directory in my src-folder which seemed to mess with git (the repository was initialised on the folder above).
After I removed the extra .git folder the problem disappered.
It can depends on the msysgit version you are using:
I just tested a tab completion on a git diff on W7 64bits, with the latest msysgit1.8.3, and it worked just fine.
Don't forget that, in addition to the msysgit version, you will have issues with tab completion due to the old bash 3.1 included in mysysgit.
And the completion can be slow on Windows.
As the OP Zeeker mentions below, the completion git-completion.bash is based on a proper git repo path detection.
# __gitdir accepts 0 or 1 arguments (i.e., location)
# returns location of .git repo
__gitdir () {
...
}
And in Zeeker's case, an extra .git folder was in the src folder, which means any completion was based from the wrong folder, which, for git diff, proved fatal.
git add seems to work though.
git-bash completion for git commands is controlled by the /etc/git-completion.bash. To fix run git-bash as administrator, then:
cd /etc
mv /etc/git-completion.bash /etc/git-completion.bash.orig
Then create a new one from the contents of https://github.com/git/git/blob/master/contrib/completion/git-completion.bash
I went out to my github repo and discovered that I had inadvertently added files to msysgit with a typo. Instead of adding files to a directory called "Domain", I added them to "DOmain".
I tried git mv, but the path is case-insensitive in Windows and the move fails.
What's the best way to resolve an issue like this?
mv to something else, like "tempdir", and then mv back to the proper capitalization?
Go back in history (git checkout someHash), create new dir with proper case, checkout the files from the wrong commit (git checkout someWrongHash someFiles), commit them, and then, reset HEAD to the new commit.
(And next time, don't torture youreslf with git on Windows ;) )
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.