4

I am using git on Windows 7 via msysgit. An issue that has been causing me a lot of grief lately is that as soon as I switch to certain branches, git thinks that some files have been changed and then I can do nothing to make it stop thinking those files have changed.

The steps to reproduce in my case (which might not be relevant to everybody) are as follows:

  1. Checkout the master branch.
  2. Checkout the pristine-3.7 branch.
  3. Checkout the pristine-3.8 branch.
  4. Checkout the pristine-3.9 branch.

At this point, git starts to assume that files have changed.

For example, here's a screenshot of a git diff output.

git diff output

Here's the diff output for the same file using Beyond Compare in Hex mode.

enter image description here

And finally, the git status output!

enter image description here

What's going on?

Update to the question:

A possible solution is to commit the changes locally and then to delete that commit without putting the changes in the commit back into the working state. How is that done?

Umar Farooq Khawaja
  • 3,925
  • 1
  • 31
  • 52
  • If there is no obvious functional difference then just use `git checkout -- filename.x` to retrieve the "original" as it is stored in the repository. – Mihai Stancu Apr 24 '14 at 11:05
  • I've tried that along with other suggested fixes, such as the `core.autocrlf` setting, the `core.filemode` setting, etc, hard resets & reverts. The only thing that sort of fixes it is committing those files. That is something I don't want to do (because I want those branches frozen). Reverting/resetting doesn't help. I've tried a `rm .git/index` followed by a `git reset --hard` as well. – Umar Farooq Khawaja Apr 24 '14 at 11:08
  • The red blocks git diff shows are trailing whitespaces. This could have to do with CRLF. Im no expert on the matter but maybe this can help you. – Tim Apr 24 '14 at 12:34
  • That was my initial thought too. That's why I carried out the hex comparison (the middle screenshot). The hex comparison shows not even a single byte different between the 2 files. – Umar Farooq Khawaja Apr 24 '14 at 13:22
  • use `git checkout filename` to get the old file back before the "changes". Have you checked the file permissions? do a `git ls-tree HEAD` and a `git ls-tree abc1234` and compare. (abc1234 should be replaced with the HEX from the previous commit) – Michael Tomkins May 04 '14 at 11:04
  • I shall try that, but in the meantime, I have ditched git in favor of hg. It ended up costing me a couple of days so I decided not to continue with use of git anymore. I appreciate your help, though. – Umar Farooq Khawaja May 05 '14 at 02:00

2 Answers2

2

Sounds like autocrlf issue. In addition, you might have smudge and clean filters enabled with a custom implementation that is causing issues.

I'd suggest doing

git diff --raw master pristine-3.9 -- packages/fop-10/lib
git diff --raw pristine-3.7 pristine-3.9 -- packages/fop-10/lib

and inspecting the results. Rest assured that git does save the binary contents and the saved binary contents matches the SHA-1 of the tip of the branch. However, the binary contents may not match the working directory binary contents if you use some features (e.g. autocrlf or smudge). The autocrlf is more prone to cause issues for Windows users because Windows users still suffer from a historical Microsoft decision to use two byte code for a single line feed instead of a single byte code used in historical UNIX compatible systems and Machintosh OS.

Mikko Rantalainen
  • 14,132
  • 10
  • 74
  • 112
2

I have this problem constantly - the only thing that works is:

git rm --cached -r . > /dev/null # redirect if output is huge
git reset --hard

but make sure you have no changes you want to keep

See git line endings - can't stash, reset and now can't rebase over spurious line endings commit

Someone must make a example repo that exhibits this behavior and post it to the git tracker - this is a bug (in the sense that git reset --hard and co should work immediately)

EDIT: make sure you have read the required reading and set up a .gitattributes file

Community
  • 1
  • 1
Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
  • Thanks for adding an answer, though after months of pain and some lost work, I jumped ship to Mercurial, which I feel is better anyway, but this might be useful for others less fortunate than I am :) – Umar Farooq Khawaja Jul 14 '14 at 09:52
  • @UmarFarooqKhawaja: I should disagree with you here - git is ohh so awesome - but yes you will hit some snags - this is probably the one I do not fully understand. But one should try to produce a reproducible example and post a bug rather than run away. Git has features mercurial simply does not have - so one fine morning you'll miss it :) – Mr_and_Mrs_D Jul 14 '14 at 12:47
  • As far as I can tell, it is Git that's lacking features, not Mercurial. What features do you have in mind? – Umar Farooq Khawaja Jul 14 '14 at 13:04
  • @UmarFarooqKhawaja: can mercurial track the move of a function from one file to another ? Can you rebase interactively your branch ? Heck - I hear it does not have an index even :D – Mr_and_Mrs_D Jul 14 '14 at 13:24