8

I clone repository switch to my branch and when i print git status i see modify files, i try to do git reset --hard but there was no effect :((

git status
On branch release

Changes not staged for commit:

    modified:   htdocs/fonts/OfficinaSansBoldC.eot
    modified:   htdocs/fonts/OfficinaSansBoldC.svg
    modified:   htdocs/fonts/OfficinaSansBoldC.ttf
    modified:   htdocs/fonts/OfficinaSansBoldC.woff
    modified:   htdocs/fonts/OfficinaSansC-Book.eot
    modified:   htdocs/fonts/OfficinaSansC-Book.svg
    modified:   htdocs/fonts/OfficinaSansC-Book.ttf
    modified:   htdocs/fonts/OfficinaSansC-Book.woff

no changes added to commit 

git reset --hard origin/release

git status
On branch release

Changes not staged for commit

    modified:   htdocs/fonts/officinasansboldc.eot
    modified:   htdocs/fonts/officinasansboldc.svg
    modified:   htdocs/fonts/officinasansboldc.ttf
    modified:   htdocs/fonts/officinasansboldc.woff
    modified:   htdocs/fonts/officinasansc-book.eot
    modified:   htdocs/fonts/officinasansc-book.svg
    modified:   htdocs/fonts/officinasansc-book.ttf
    modified:   htdocs/fonts/officinasansc-book.woff

no changes added to commit
Ivan
  • 91
  • 1
  • 3
  • See [`git clean -df`](http://git-scm.com/docs/git-clean). – user2864740 Dec 19 '14 at 21:34
  • 1
    Please explain your question in the *body*. – jub0bs Dec 19 '14 at 21:35
  • git clean -df did't help – Ivan Dec 19 '14 at 21:36
  • In your question, you write `autoclrf`, but the correct key is `core.autocrlf` (note that "r" and "l" are swapped). Is that a typo in your question or in your config file? Did you edit your config file manually? – jub0bs Dec 19 '14 at 21:39
  • I have problem with modified files and i print my .git/config core options for more understanding my situation – Ivan Dec 19 '14 at 21:42
  • i would do git diff htdocs/fonts/officinasansc-book.woff and see what's actually changed , it's probably a file permission issue... you can also try git reset --hard – wonde Dec 19 '14 at 22:02
  • diff --git a/htdocs/fonts/officinasansc-book.woff b/htdocs/fonts/officinasansc-b index f65eecc..11f16fa 100644 Binary files a/htdocs/fonts/officinasansc-book.woff and b/htdocs/fonts/officinas – Ivan Dec 19 '14 at 22:06
  • Possible duplicate of [git line endings - can't stash, reset and now can't rebase over spurious line endings commit](https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en) – Mr_and_Mrs_D Dec 26 '18 at 21:41

3 Answers3

8

The issue with having a core.autocrlf to input is that it can change eol (end of lines) characters even for (binary) documents that should not be touched.

Try: 

git config --global core.autocrlf false
git clone /url/your/repo

(meaning clone again your repo, and see if those diffs are still there)

With git 2.8 (March 2016), you will able to quickly check if those changes are eol-related.

See commit a7630bd (16 Jan 2016) by Torsten Bögershausen (tboegi).
(Merged by Junio C Hamano -- gitster -- in commit 05f1539, 03 Feb 2016)

ls-files: add eol diagnostics

When working in a cross-platform environment, a user may want to check if text files are stored normalized in the repository and if .gitattributes are set appropriately.

Make it possible to let Git show the line endings in the index and in the working tree and the effective text/eol attributes.

The end of line ("eolinfo") are shown like this:

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

The effective text/eol attribute is one of these:

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

git ls-files --eol gives an output like this:

i/none   w/none   attr/text=auto      t/t5100/empty
i/-text  w/-text  attr/-text          t/test-binary-2.png
i/lf     w/lf     attr/text eol=lf    t/t5100/rfc2047-info-0007
i/lf     w/crlf   attr/text eol=crlf  doit.bat
i/mixed  w/mixed  attr/               locale/XX.po

to show what eol convention is used in the data in the index ('i'), and in the working tree ('w'), and what attribute is in effect, for each path that is shown.

VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
3

I also met same problem. When i run command git diff, the result is:

Binary files a/app/webroot/font-awesome-4.4.0/fonts/fontawesome-webfont.ttf and b/app/webroot/font-awesome-4.4.0/fonts/fontawesome-webfont.ttf differ
warning: CRLF will be replaced by LF in app/webroot/font-awesome-4.4.0/fonts/fontawesome-webfont.ttf.
The file will have its original line endings in your working directory.

I tried git reset --hard . but it did not work. But when *.ttf binary is appended into .gitattributes file, the reset command worked.

Cheer.

Nguyen Van Vinh
  • 2,384
  • 1
  • 11
  • 10
  • For me also helped adding `*.svg binary` to `.gitattributes` and doing `reset --hard`. Weird. – Alex78191 Nov 03 '17 at 23:45
  • I needed to commit the `.gitattributes` diff and remove and add the `.ttf` file in order for this to work with git version 2.21.0 (Apple Git-120). – Roger Campanera Aug 13 '19 at 13:25
0

The reason it does not work is conflicting line ending info passed to git. Try:

git ls-files --eol | grep /path/to/problematic/file

You can add a line to .git/info/attributes file to mitigate the problem. See my answer here for details

Mr_and_Mrs_D
  • 27,070
  • 30
  • 156
  • 325