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.
Related
I have had git LFS enabled on my repository for a while and it has always worked perfectly. Recently, I have been having issues where my local files are being replaced with links.
As an example, I have a png file that will no longer open because the file format is not supported. Upon opening the file in notepad, I am presented with this.
version https://git-lfs.github.com/spec/v1
oid sha256:733c51c9ee6f0f395f5f042869307154d6ebf6d5d5e3bc10e2af68a432903bf0
size 5104
Many of my files are being replaced with these links and my programs that are accessing these files are throwing errors as they are unable to read them.
I am working in Windows 10, I have git lfs installed, I am using git-bash on the Windows Cmd line. I believe that when I was installing git-bash, I enabled symbolic links, I am unsure if that could potentially be causing the issue.
If you need more information, please let me know. I really appreciate everyone's help!
These are the pointer files that Git LFS uses to track objects. The fact that you're seeing them means that the proper filters for your repository aren't set up. Run git lfs install within your checkout to install the filters both in your repository and in your ~/.gitconfig.
Once you've done that, you can run git lfs checkout to fix the current repository, and then Git LFS should work normally when you check out a branch. If you modify or replace your ~/.gitconfig file, be sure to keep the filter entries that git lfs install inserted there.
The proper commands to set the options are as follows:
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"
It's much easier to invoke git lfs install, though.
I've got a computer with windows 7 in which I've recently installed Git (with Vim inside the Git directory). I tried installed pathogen and apparently it is installed correctly since there are no error messages with pathogen in autoload. My _vimrc is located in Users/Username which is $HOME and it the following is relevant to pathogen.
execute pathogen#infect() //_vimrc starts with this line
call pathogen#helptags()
syntax on
filetype plugin indent on
the path to autoload and bundle is:
C:/progra~1/git/usr/share/vim/vim74/autoload(and vim74/bundle)
When I clone a plugin (ex. NerdTree) to bundle, the following message appears when I open Vim.
Error detected while processing /usr/share/vim/vim74/bundle/nerdtree/plugin/NERD_tree.vim:
line 16:
E15: Invalid expression: exists("loaded_nerd_tree")^M
line 211:
E171: Missing :endif
I also start a session in vim and use
:help NERD_tree.txt
but it returns "Sorry, no help for NERD_tree.txt"
Does anybody know what is causing the problem and has the solution?
First
All your configuration is supposed to happen in $HOME/.vim/ (plugins, colorschemes, etc.) and $HOME/.vimrc (options, mappings, etc.). Note also that, since Vim 7.4, it is possible to have your vimrc directly inside $HOME/.vim/, which makes managing your configuration even easier.
Whatever you did in /usr/share/vim/ should be reverted ASAP.
Second
But your issue is caused by line-endings: the cloning process changed the ones used by the author — lf — to the standard ones on Windows — crlf. Because Vim only accepts lf it was unable to source your plugin.
The cause is most likely the value of core.autocrlf in your Git settings.
The command below should prevent Git from converting lf to crlf upon checkout/clone/pull/etc.:
git config --global core.autocrlf false
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.
I have a remote SVN repository and a local git repository. Using git-svn I have linked git to SVN and am successfully using git svn rebase, git svn dcommit to pull and push to the remote SVN repository.
However, when other people check out my previously-git-edited files with SVN and try to open them in VS2010, they receive a dialog telling them the line endings are inconsistent.
I've read a few things about the core.safecrlf option in git config, but would that fix my issue? I have a number of other people checking in, but we're all running windows - I figured the line endings would be the same?
Would setting core.safecrlf preserve the same type of line ends on checkout and on commit?
I have been dealing with this same issue lately. By default, Git on Windows sets core.autocrlf = true. What happens is that your files are checked out from the SVN repo with CRLF line endings, but are committed with unix-style (LF) line endings. When you dcommit those changes, I believe the files are pushed to the SVN server with the unix-style line endings as well. Now when someone checks out those files using SVN, no line ending conversion is performed.
You can set core.autocrlf = false so that no conversion is done. If you are all working in Windows, you shouldn't have any problems. If you are sharing the SVN repo with *nix users, then it is likely that you'll start having inconsistencies. This is the reason for the autocrlf option. The repos should remain consistent, and since Linux doesn't like to play nicely with CRLF, this autocrlf should be set to true.
Line endings problem is a well-known headache of git-svn. I would recommend to use SmartGit to work with your repository. I respects svn:eol-style value to use correct EOL in Git (translating to it to a corresponding .gitattirbutes value). You may also control svn:eol-style value on pushing to SVN by appropriate changes .gitattirbutes.
If you have an access to the server another approach is possible: just install SubGit into your SVN server. Then a linked Git repository will be created on the server such that every push to it will be automatically translated to SVN and vice versa. It also translates svn:eol-style to .gitattirbutes.
So I would recommend one of these solutions, but not git-svn that is (as I know) painfully slow on Windows.
Here is a GitHub article that describes your choices for handling end of line characters in Git:
https://help.github.com/articles/dealing-with-line-endings
Essentially Git helps convert EOL on different OS's. SVN has similar functionality. You will need to ensure that they are set in a consistent manner.
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.