I\'m want to be able to work on my git projects using both the Github for Windows application as well as git in the command line using Cygwin (on Windows).
But I keep o
This is a GHfW bug which occurs when your repository configuration and the data in your repository do not agree.
If you configure a file to be translated to CRLF line endings - by setting core.autocrlf
to true
, for example, but you have blobs in your repository that are already in CRLF format (likely because somebody hasn't set core.autocrlf
to true) then this problem can occur.
In this case, GHfW translates the CRLFs in the repository differently than msysgit. As a result, some or all files appeared dirty.
I would recommend a consistent approach to your CRLF across your team to avoid any ambiguity by git tools as to what they should do with your line endings. That said, this bug was recently fixed in libgit2, the library that underlies GHfW, and should makes its way into GHfW soon.
I cloned a repository (with files with CRLF) on my windows using GitHub 2.7.0.24. Then I wanted to use my cygwin's git version 2.1.4 on it.
I edited .git/config by adding "autocrlf=true" under the [core] section. (With a real tabulation before "autocrlf=true")
Now cygwin's git says I'm up to date with no modifications.
I keep the CRLF on the files because they were created that way on the original repository.
I will not use the GitHub application anymore...
I noticed the merge conflicts are adding <<<< ==== >>>> lines with no CR, but they will be deleted when I resolve the conflicts.
Working on both Git Bash and Cygwin in Windows is going to make git confuse. That is:
CRLF
to check out text files.CRLF
in Cygwin, it thinks that LF
is modified into CRLF
so that git reports a lots files changes.One way to fix this is to create .gitattributes
file in repo's root and
add lines like the following:
*.txt text eol=lf
It tell git when encounter file with suffix .txt
, using LF
both when
writing into "database(.git)" and checking out into working directory.
reference here