I've converted an SVN repository to Git by following this tutorial. And now cannot seem to extract a sub-repository like suggested in this answer.
Forgive the long post but most of the text is the nicely formatted git output.
OS: Windows 8 Command line: MinGW Git version: 1.8.1.msysgit.1
The process of extracting a subrepository doesn't seem to work unless you have a clean staging area and no modified files.
git status tells me that I have a modified file even though this is a fresh SVN import. Ok, let's just try and get rid of it.
Try and revert the file.
user$ git status
# On branch master
# 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: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
user$ git checkout -- "folder with space/folder/toolbar.png"
user$ git status
# On branch master
# 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: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
This didn't work, but I don't really care if I commit it so I'll try that next.
user$ git commit -a -m "Testing if committing fixes it"
# On branch master
# 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: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
user$ git status
# On branch master
# 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: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
Committing by skipping staging doesn't work, so let's try and stage it first.
user$ git add "folder with space/folder/toolbar.png"
user$ git status
# On branch master
# 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: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")
Doesn't work, so I'm stumped... Go and ask someone smarter.
I'm new to git but am familiar with Hg and have been reading this online tutorial to get myself started.
It is entirely possible that I've messed up a simple command.
Already tried: I looked around for a solution to my particular problem but have had little luck. I've stumbled across this answer which seems related but does not quite fix my problem.
Edit: Things that might be interesting
This is the part that confuses me. I've pushed this repo a while ago into an online repository. After a fresh clone the repo still thinks that the file is modified (i.e. git status returns the same result, and I've already set git config --global core.autocrlf false and verified by running git config --global core.autocrlf which indeed returns false).
Edit 2: Fix found, but the problem is still not understood I've managed to fix the repository by simply removing the file from the system, the staging area and then committing the changes. After this to get the file back I've simply copied it back and committed it to the repository.
The problem, though fixed has only confused me more.
While I was playing around with removing the file I noticed that if I reset the repository to the HEAD, whose last commit has removed the file, git status would indicate that nothing has changed and that the file is not tracked but the file would be restored in my working tree. This is odd considering that it is flagged as removed in git...
Only after removing it a second time, even though git no longer remembers it, did I manage to actually remove it so that git reset and git reset --hard don't restore the file.
If somebody can please explain how I got into this state and if it is a bug in git or normal behavior I would greatly appreciate it.
My suspitions
I've lost the sequence of commands that I used but what happened went something like this:
The file is Images/toolbar.png, and I've navigated into the Images folder.
After I deleted it from the file system git detected the change like so:
# On branch master
# 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)
#
# deleted: toolbar.png
# deleted: ../images/toolbar.png
#
Note the fact that the images folder is not capitalised! This is being run in Windows which ignores the path case. I suspect that this might be a part of the problem...
I'm really confused but my problem is gone. So this post remains only as a curiosity, although I can't replicate the behaviour it lives in the conversion from SVN somewhere.
I had a similar issue a while back.
Did the capitalization on this file, or the directory it was in change at any point?
I had a directory with a capital letter that was changed to all lowercase (let's say it went fromt /Foo to /foo). It gave me all the same problems you've described.
Whenever I modified a file, it gave me similar output to this:
# modified: bar.txt
# modified: ../Foo/bar.txt
I also had the same problem where committing or resetting wasn't producing any results.
I think the cause of the problem is that Windows file paths are not case-sensitive, but Unix ones are. Since a lot of these command-line tools like Git are developed on Unix-y systems, they sometimes don't handle this difference well, and can get confused when a file is added as Foo/bar.txt and foo/bar.txt. I think this makes Git think there are two different files, where there's actually only one.
My eventual fix was the same as yours, remove the entire directory from history, then re-adding it (and never changing the capitalization ever again). This also caused the same weirdness you described where I had to remove it twice before it took.
Anyway, I know this isn't a definitive answer, but I've since been able to recreate the problem, so I'm pretty sure that's what caused it (at least for me).