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
Related
I'm running Windows 7, and I have the latest version of git (2.7.2.windows.1). I previously used Windows PowerShell as my terminal for git operations, with no issues. Recently, I decided to switch to Git Bash, but I'm having one major issue.
My project has a directory (within which are many subdirectories) whose name is simply an underscore. Whenever I try to run git diff on a file within that directory, I get the following error:
$ git diff _/css/templates/jquery.tag-editor.css
fatal: Invalid object name '_C'.
As far as I know, an underscore is a perfectly valid character in a file/directory name, and tab completion works fine within that directory, so I know the terminal can "see" inside it. Additionally, other contributors to the project, all of them running OSX, do not have this problem. And when I run a simple git diff, without specifying any single file, it works fine, and happily includes the diff for any changed files within the underscore directory. It also works if I cd into the underscore directory and run the git diff from there, so that the path I pass to it does not include the underscore.
What exactly is happening here to prevent me from running git diff on these files? And where does the "C" come from in the error message when I try to do so?
Update
When I run git checkout -- _/css/templates/jquery.tag-editor.css to discard the changes to that file, this is the error I see:
error: pathspec '_C:/Program Files/Git/css/templates/jquery.tag-editor.css' did not match any file(s) known to git.
C:\Program Files\Git is directory of my Git installation. So apparently part of the path is being interpreted as referring to the Git installation directory? Again, what is causing this to happen?
The problems you are experiencing are based on the Posix Path conversions of MinGW/Msys2.
on git-bash try to double a slash: git diff _//css/templates/jquery.tag-editor.css or use backslashes (which need to be escaped in git-bash): git diff _\\css\\templates\\jquery.tag-editor.css or prepend MSYS_NO_PATHCONV=1: MSYS_NO_PATHCONV=1 git diff _/css/templates/jquery.tag-editor.css
on CMD you should use a backslash instead of a slash: git diff _\css\templates\jquery.tag-editor.css OR double a slash as for git-bash
in order to prevent the conversion.
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
Using git svn fetch to do some local work (using git personally), I got a file that will not "reset". I see that it's different from similar files in the same directory in that it has a backslash as part of the name: icon#2xios8\.png. I suppose the backslash doesn't do anything on other platforms but msysgit on Windows 10 complains that it's unable to create the file.
I can't figure out how to make git ignore this subdirectory and let me continue with unrelated work. But I really need to fix it somehow so git can be used.
You can do this with git-read-tree and sparse checkout (git-read-tree).
Therefore you call
git config core.sparsecheckout true
Then create a file .git/info/sparse-checkout (with touch .git/info/sparse-checkout in msysgit bash). Edit this file and change its content to:
/*
!icon#2xios8\\.png
This tells git to look at all files in your working directory (/*) but '!icon#2xios8.png' (!icon#2xios8\\.png). Notice the escaped backslash here (\\)!
After you run git read-tree -mu HEAD you should be able to pull your repository by ignoring that specific file.
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.