I've got an odd problem. Using Octopress on OS X, which uses a Rakefile (ruby) to setup deployment folders and such with a unique Git repository structure.
The problem is this line:
system "git add -A"
...in the Rakefile generates this error:
fatal: Will not add file alias 'blog/{obmitted-dir-name}/index.html' ('blog/{OMITTED-DIR-NAME}/index.html' already exists in index)
Ok, so this sounds like a casing issue and I should issue:
$ git config core.ignorecase false
Nope, still the same error and I've verified it is set to false now. So then I issue:
$ git config --global core.ignorecase false
Still no go.
And now for the odd part... I can manually change directories to my _deploy/ dir and issue the command manually:
_deploy/$ git add -A
No problem!
I've verified this numerous times... The Ruby Rakefile cannot issue git add -A, whereas I can do it manually.
I even stopped the script directly on that step and did it manually.
Does Ruby have a different Git environment it runs from?
Is OSX case insensitive even with setting that git flag? If so, that's my problem and I'll never be able to deploy from OSX (just like I can't deploy from Windows): I have upper and lower case aliases for 404s to redirect.
It turns out the issue is indeed that OSX is case-insensative (I didn't know this!) - which in turn doesn't allow git to perform the aliases of different casing.
That's the same issue I had on Windows and is why I moved to Linux. Looks like I'll have to keep a Linux VM handy to handle updates to my static blog (Octopress/Jekyll) cause I do have traffic on both casing of the urls.
If you are reading this and want to remain on OSX with mixed-case blog posts, the answer would be to create a virtual disk that has case sensitivity, mount it permanently and move your Octopress/Jekyll install to it. See: https://gist.github.com/dixson3/8360571
As mentioned in the other answer: macOS (standard hard drive partition) is case insensitive. That means your local git should be the same too.
So, do not do git config core.ignorecase false as that will mess up the things more. Also, if you rename a folder to uppercase, git doesn't track the change, except if you change the files included. So, it is very easy to miss that.
The solution that worked for me is:
Copy all the folder in your case "blog" to a safe place.
Delete with git rm -rf both folders ({obmitted-dir-name} and {OMITTED-DIR-NAME}).
Add and commit the changes.
Create the blog folder again and paste your content with the folder name you want to keep.
Add and commit the changes.
You will need to do that in all related branches too.
Related
I am trying to build some code in Linux and I am getting the error:
'\r': command not found
Now I know this question has been asked in general before and I have already read the answers to them. In this question I am asking for a clarification for my particular situation.
In those questions, the reasons for that error has already been explained: The existence of an invisible character that gets interpreted as a command.
One suggested solution has been to modify the files to eliminate those characters. This solution is not feasible in my case for two reasons:
It is impractical to go and modify all the files involved
It has been expressly ordered to me that I cannot modify the files.
One solution recommended here and here suggest to modify the EOL behavior in Cygwin by setting an option to ignore CRs:
The problem is that this igncr option has so few documentation that I couldn't find details on this. Is this option available for linux systems too?
(For reference I am working on a git bash in windows to manage the repository but I build the code after transferring it to a linux workstation inside a docker container)
The other possible solution I found was this one in which it was suggested to modify the git settings in order to configure Git to not convert line endings on checkout:
How does this config works? In the linked answer it says
git config --global core.autocrlf input
when I do git config --list in my windows machine I get
core.autocrlf=true
Should I change the config and clone my entire repository again??
I am looking for clarifications on these two possible solutions but any other solution (that does not involve modifying the files) is fine too
Just for reference
I git manage locally a repo on a windows machine. Once finished I transfer the code to a remote linux machine and I build the code there. There is where the problem with \r appears
First, for reasons explained in "What is the correct core.autocrlf setting I should use?", make sure to add:
git config --global core.autocrlf false
Second:
try and fix your partical file eol (dos2unix or other commands), and
add in a .gitattributes file a myfile eol=lf directive to force said file to keep the right end-of-line sequence.
I'm getting this message when trying to rebase interactively using source tree.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
fatal: Unable to create 'X:/sources/project/.git/index.lock': File
exists.
The problem is that X:/sources/project/.git/index.lock doesn't exist
All the other solutions on SO didn't work for me since they all say to remove this file.
I'm on a Mac and ran into basically the same issue.
When running git rebase -i master, I received an error:
fatal: Unable to create 'path/to/file/.git/index.lock': File exists.
The index.lock file didn't exist in my .git/ directory. But there was an index file (no filetype extension). So I aborted the rebase.
After a ton of searching, I finally decided to just create the file:
touch .git/index.lock
I tried rebasing again, but that didn't fix the issue (this time the file really did exist). So I removed it:
rm .git/index.lock
That did the trick. The rebase had conflicts this time (which was odd since I aborted the rebase previously), but I just addressed each conflict and then let the rebase continue:
git rebase --continue
I hope this helps someone else who ends up in a similar situation.
Use rm -rf X:/sources/project/.git/index.lock to remove the lock and save yourself a headache. Also, the index.lock exists, however, the .git folder is hidden. So, use ls -la X:/sources/project/.git to see the content of a hidden folder.
I had the same issue using Github Desktop. I watched the .git directory and the index.LOCK file would appear and disappear. It never persisted for long, so was not there to delete. I investigated a little as other solutions online did not work for me and found that comparing permissions to folders that I was able to commit they had one difference: the .git folder that gave me the error had full control like the others, but it was inherited from its parent. I went to properties->security->advanced and removed then re-added the permissions without inheriting them from the parent. After that I was able to commit my changes without an error.
OK, this is really strange, but for me, the following worked:
Create the file .git/index.lock from Windows explorer
Delete the file again (from git bash, I don't know if this is important)
Then, the command I was executing (git rebase --continue, in my case) succeeded. I have no idea why this procedure worked, though. This should not make any difference...
I disabled indexing of the .git folder and it helped to me to get rid of the message
#Manza: I came across the same issue. There is no index.lock file existing and still it throws an error related to file existence.
I created a patch of my changes and did a clone again. Now when I do a commit, it works all fine. I know this is not the right direction. But this is the go to when the index.lock doesn't get created and still we get this error.
for ios mac remove rm -rf from this location .git/modules/ios or can manual delete
Step —
1)-Open terminal .
2)-Open project file location.
3)-Rum command - defaults write com.apple.finder AppleShowAllFiles YES.
Now u can see hidden file in Mac OS.
4)-Rum command - cd .git/modules/ios (In my case I am running React code).
5)-Now either open folder and delete index.lock or use “rm” command .
6)-Thats its - now try to commit and push .
I just used a "git clean" command and managed to delete my Documents, Music, and other directories. Is there a way to undo this and somehow get those files back? I did this via Terminal on Mac. Time Machine isn't setup either.
I'm afraid those files are gone. git clean is not reversible since those files were not tracked by git.
From the comments it looks like you had your home folder as git repo, but with nothing tracked.
Running git clean -f removed any file inside the home folder (included the one in the subdirectories), leaving only empty subdirectories (the -d option is required for removing them too).
I'm sorry to inform you that you definitely wiped out your whole home directory. Next time you run a git clean use the -n options to perform a dry run and check what's going to happen before it's too late.
Unfortunately git clean removes all the untracked files, meaning the files that are deleted are not able to be recovered using git. You might be able to check your trash to see if the files still exist there.
I have just recently backed-up my XCode C++ project on my pendrive, using
rsync -avu
Since then, the version control for my project is grayed-out on every files, I can modify the files and not see the "M" nor the "A" sign. The only files still having version-control working "shared" files for which it works correctly. (Those shared files belong to a different project called "Shared").
I have tried git commit -m, git add . and even git init where the files were. Nothing worked.
Can you please help restoring version control for my project?
UPDATE:
Answers for the questions in commens (and answers):
my git repository is on my local hard drive.
I went to the Organiser-repository pane in XCode and I see my recent git commit -m "sth" as "sth" az a commit. I have a single branch: master.
Im not sure what command would be good to test git, as my commits work (theoretically).
I have a folder named .git in the project folder.
git log is working, showing the same as XCode Organiser-repository pane.
I think the XCode just can't synchronise with the git for some reason, and I don't know how to correct that.
First off, this is not an answer that will fix your problem, I just try to provide some help that might get you closer to a diagnosis.
Git stores its files in a folder named .git. Check if this folder is present in your project. If it's not then your Git repository is gone.
Next, try some basic command such as git log. For this to work, you must first cd to your project folder (or a subfolder thereof), because whenever you run a Git command it will look for the .git folder in the cwd or a parent folder. If git log does not work then your Git repository is broken in some way. Someone else will have to step in to further diagnose the problem, as I am no expert on this subject.
Finally, you should also check whether your rsync command has really sync'ed your project's .git folder with the backup's .git folder. Use this command:
diff -rq /path/to/project/.git /path/to/backup/.git
If there is no difference (as I would expect if rsync has worked correctly) then the problem with your Git repository is both in your project and in your backup. If there are differences then it might be worthwile to try your next steps on a copy of the backup (it should be fine to make the copy in the Finder).
Good luck.
I'm not too sure what is going on here, but sometimes a particular file in my repository will change the case of its name. e.g.,:
before: File.h
after: file.h
I don't really care why this is happening, but this causes git to think it is a new file, and then I have to go and change the file name back. Can you just make git ignore case changes?
[edit]
I suspect it is Visual Studio doing something weird with that particular file, because it seems to happen most often when I open and save it after changes. I don't have any way to fix bugs in VS however, but git should be a bit more capable I hope.
Since version 1.5.6 there is an ignorecase option available in the [core] section of .git/config
e.g. add ignorecase = true
To change it for just one repo, from that folder run:
git config core.ignorecase true
To change it globally:
git config --global core.ignorecase true
You can force git to rename the file in a case-only way with this command:
git mv --cached name.txt NAME.TXT
Note this doesn't change the case of the file in your checked out copy on a Windows partition, but git records the casing change and you can commit that change. Future checkouts will use the new casing.
In git version 1.6.1.9 for windows I found that "ignorecase=true' in config was already set by default.
The situation described in the question is now re-occuring with Mac OS X, git version >= 1.7.4 (I think). The cure is to set your ignorecase=false and rename the lowercased files (that git changed that way, not Visual Studio) back to their UsualCase by hand (i.e. 'mv myname MyName').
More info here.
To force git to recognize the change of casing to a file, you can run this command.
Change the File casing however you like
git mv -f mynewapp.sln MyNewApp.sln
The previous command seems to be deprecated now.
From the console: git config core.ignorecase true
Change file name capitalisation
Commit
From the console: git config core.ignorecase false
Step 4 fixed problems checking out branches with a different capitalisation.