Git status shows file twice but different case - windows

I tried to do a search for my issue and the closest thing that I could is this.
git Status Shows Same File Twice - But with different path slash styles
But it doesn't seem to be the same issue I have.
I was doing a commit and noticed that the same file was listed twice but with different case. For instance, Directory/resource.h and Directory/Resource.h. Now there is only one file in the directory resource.h. If I look at the file through Git Extensions they look exactly the same. There doesn't seem to be another hidden file, there is only one file.
So I tried to fix this by removing the resource.h file, committing, and then adding the file back and recommit again. Only one file showed up as added. I thought I fixed the issue, but now if I try to checkout a different branch I get the following error.
error: The following untracked working tree files would be overwritten by checkout:
Directory/Resource.h
Please move or remove them before you can switch branches.
Aborting
Done
I don't really have any idea what to do from here, I've only been using Git for a few months and I haven't had to do anything more complicated than merging branches and pushing and pulling.

This can happen in Windows if you have a repo with ignorecase = false and rename a file without using git. To fix, this should work
git mv -f Resource.h resource.h
git commit -m 'fix case'
and this should prevent it from happening again.
git config core.ignorecase true

Related

Is it possible to fix Windows altered case of file names with pull from remote git repo?

I have a problem where a Windows file restore changed the case of some file names. This causes a trainwreck with some projects.
Fortunately these projects are pushed to remote git servers. The remotes are up to date with origin/master, and cloning the projects is a solution. The only problem with that is the time-consuming task of replacing git-ignored files and dealing with other updates.
An ideal solution would be to pull down all files from the remote, overwriting the files in the origin/master. Is this possible? How do I force a pull down or merge, even though they are already a match. I want to keep it that way, just use git to rewrite the correct file name cases.
git pull or git pull -f results in Already up-to-date.
First, set git to be case sensitive. By default this was set true to match Windows:
git config core.ignorecase false
Check the list of changed-case file names Windows messed up. At the very least, this is your list of files to fix:
git status
Now, delete the files and folders that are messed up. Do not delete git ignored files! Files in .gitignore must be fixed the hard way.
Now, get your deleted files back as they were before Windows changed the case:
git checkout .
Yet another reason to quit Windows.

Backing out staged changes in Mercurial on a Mac

I just cloned an hg project that is typically maintained by Windows users (I'm an a Mac). I just did an hg add . and got a bazillion of the following messages:
adding out/blah
adding out/meh
adding out/fizz
adding out/buzz
...etc.
I do not want anything under out/* getting committed & pushed! So I added the following entry to .hgignore:
out/*
And then re-ran hg add .. Have I successfully prevented all this cruft living under out/* from being committed & pushed to the remote repo? If not, what else (specifically) do I need to do, and in what order?
First, check with
hg status
which files were actually added (you can also use hg status -a to restrict yourself to added files). Unless you removed them, the files in out still remain added. In order to get rid of them, use:
hg forget out
Then use hg status or hg status -a again to verify that they are no longer part of the planned commit.
I'll also note that out/* will also exclude any files in subdirectories that are named out, e.g. foo/out/bar.txt. To ignore only files in the directory out at the root, use the following line instead for your .hgignore:
re:^out/
The re: prefix will use regular expression matching instead and ^out/ will match all paths that start with out/.

Git: Unable to discard changes due to line endings?

"Out of the blue" I've started having this issue with a git repository that I have hosted on GitHub.
Whenever I pull a remote branch to my computer (even on the first clone of the repository) an arbitrary (?) set of files appear as "Changes not staged for commit". I am running on Windows 8.1 and using SourceTree alongside Git Bash as git clients.
An examination of the changes in these files shows that nothing has changed in them, except, maybe, the line endings. I don't know how to view the line endings when diffing so can't be sure.
When I try to "discard" these changes, it simply doesn't work. git reset --hard simply has no effect and the changes remain in place.
Why is this happening? How can I make it go away? :)
PS - When I run git config -l I see core.autocrlf=true appear 3 times in the list.
PPS - I have a .gitattributes file in the root of the repository. Deleting it does not have any effect on the above symptoms. It was first added a few days ago. It's all commented out except for * text=auto in the beginning of the file.
UPDATE:
I've found the minimum steps to reproduce my issue:
I open a file in a text-editor, add a single space somewhere and save it.
The file appears under "Changes not staged for commit" (obviously).
I remove the single space from the file and save it.
The file remains under "Changes not staged for commit" even though both SourceTree's diff and Kdiff3 show that the file is binary equal to its previous version.
Please note that the file in this example had CRLF line endings before I edited it and after I edited it - I don't understand why git insists on marking the file as changed.
UPDATE 2:
Running git diff --raw MyProject/app.config where MyProject.app/config is one of the files marked as changed gives:
:100644 100644 b960510... 0000000... M MyProject/app.config
The fact that the second SHA1 is all zeroes looks like a clue to me - but I don't know what it means.
This is a common problem when you set core.autocrlf after the fact. You can try this procedure from GitHub help. Another easy solution is to just clone a new local copy of the repository, which can also be a good troubleshooting step if you're still having problems.
UPDATE 3: I was able to resolve my issue by removing the .gitattributes file from the root of my repository.
The most likely suspect for having added this file into the repo in the first place is Visual Studio 2013 are per this Microsoft Connect issue.
I still don't understand why having this file (with this core.autocrlf=true in it) caused the behavior that I observed. If anyone has a good explanation, please post it as an answer and I will accept it.
Following the github article on dealing with line endings you can see that setting text=auto on the .gitattributes file tells git to "handle the files in whatever way it thinks is best." Seeing that the rest of the file was commented, and you had a star on text=auto, this was applied on everything. I suppose that in your case, what git thought was best, turned out to be the wrong choice.

error: Sparse checkout leaves no entry on working directory

First, let me tell you that I have already checked all the similar threads and searched google to find what the problem may be, but no success. My problem is that I'm trying to use sparse checkout in git, but I get this error:
error: Sparse checkout leaves no entry on working directory
I have this 60GB repository, which I need to clone. I need only a part of it, so to save a disk space I wanted to use sparse checkout. This is what I do:
mkdir repoDir
git init repoDir
cd repoDir
git remote add origin <repo url>
git config core.sparsecheckout true
echo "some/dir/" >> .git/info/sparse-checkout
git pull --depth=1 origin master
Note I add the remote without -f flag, so nothing is fetched.
The result:
error: Sparse checkout leaves no entry on working directory
I tried several things:
Instead of initialising new repo and adding the remote manually, I did git clone --no-checkout and then set up the sparse checkout. This didn't help as my git status showed as if I deleted all the files in my repo. The git pull origin master command results in the same error.
Tried all possible combination of paths in step 6, with preceding slashes, slashes after the path, stars, spaces between path and > or >>. Btw I'm confused what is the correct format here, from the comments on SO I see mutually exclusive ways of formatting this.
Tried to make sure my .git/info/sparse-checkout is ASCII, and has proper line endings as found here. This is probably only problematic on Windows, but I just checked this anyway.
My git version: git version 1.9.3 (Apple Git-50)
OSX Yosemite 10.10.2 (14C109)
It turns out that "some/dir/" was wrong, since I didn't have the repository I didn't know it's real structure. I was able to browse it through web interface but I just discovered the folders don't correspond exactly to the real repository folder structure.
Lesson for the future: make sure you know the folder structure before creating sparse-checkout file.
The sequence of operations I wanted to follow is similar, namely the one suggested in this other post https://stackoverflow.com/a/13738951/5459638. I get the error message
error: Sparse checkout leaves no entry on working directory
when launching git pull <remote> <branch> with branch being master.
As #lawicko said, in the project webpage I can click my way to the subdirectory to be cloned and copy the URL of that page; ctrl+L ctrl+C makes doing this nice and quick. This URL has the form
https://gitlab.com/<username>/<project>/tree/master/<subdir>/<subdir>
The part that my sparse-checkout file accepts is the children of master
<subdir>/<subdir>/
with the trailing slash.
As an alternative to the same aim, there is another path in the form <project>/<subdir>/<subdir> to the right of the drop-down menu for switching branches at the top of the webpage.
In this case, I would have copied and pasted the children of <project> plus the trailing slash.
And this path is not as easy to copy and paste as the URL is.
Note that if you are using sparse-checkout on windows, you may need to add core.protectNTFS false per https://github.com/git-for-windows/git/issues/2777

Git (windows 7) won't add directories, but adds files files typed explicitly

trying to find an answer to this, have seen it hinted at, but no solution.
Not entirely new to git, but haven't used it in a few months... this is my first time using it on windows. using git bash.
I have a cake PHP site that I want to add exluding any cache files my .gitignore file contains only:
app/tmp/*
Here is the most basic thing I have tried:
git init
git add .
git commit
I get a message on commit saying there are untracked files - all files and dirs at the root directory.
git status
gives me the same message.
However, if I type
git add .htaccess
it stages the .htaccess file.
Also, if I do:
git add app/.htaccess
It will add that file too.
I have also tried
git add app/*
no luck.
Thanks in advance.
The files aren't ignored, because otherwise you would be forced to do a git add --force afile.
However, you might want to check GIT_DIR and GIT_WORK_TREE environment variable, and see if they reference another repository, which could explain the discrepancy between the index and what you think is your working tree.

Resources