10

Here is some pertinent output from the command line (with poshgit showing the status):

[Branch1]> git checkout Branch2
Switched to branch 'Branch2'
[Branch2 +0 ~3 -0]> 
[Branch2 +0 ~3 -0]> git diff --ignore-space-at-eol
[Branch2 +0 ~3 -0]> git checkout .
[Branch2 +0 ~3 -0]>

I tried the solutions suggested in this question

[Branch2 +0 ~3 -0]> git reset --hard
HEAD is now at c8be749 some comment
[Branch2 +0 ~3 -0]> git reset HEAD
Unstaged another commit:
M       Src/somefile
M       Src/someotherfile.cs
M       Src/athirdfile.cs
[Branch2 +0 ~3 -0]>

how does this happen and how can I fix it apart from committing the changes as I seem unable to undo the differences. Even stashing does nothing.

Some suggestions for how we got into this mess and how we can get out of it would be much appreciated.

I have been able to reproduce this reliably now so am in a position to get a more definitive answer. If I freshly clone me repo, then switch to a branch and then back to master I get some files which say they have changes. I have tried playing with the settings of core.autocrlf but that just seems to change the number of files that are affected and doesn't solve the problem completely.

What can I do to try and fix this increasingly annoying issue?

Community
  • 1
  • 1
Sam Holder
  • 32,535
  • 13
  • 101
  • 181
  • You're ignore spaces in the diff call there. Is that because there are whitespace differences? – Gary Fixler Dec 06 '13 at 16:31
  • 1
    @Garyfixler I'm ignoring whitespace differences in the diff check to show that the issue is only with whitespace. – Sam Holder Dec 08 '13 at 10:17
  • an other pertinent output would be `git status` – Asenar Feb 11 '14 at 13:00
  • @SamHolder do you see a change in the case of the parent folder (like '`src`' in one branch and '`Src`' in the other)? – VonC Feb 11 '14 at 13:01
  • @VonC no the folders casing is the same – Sam Holder Feb 11 '14 at 13:02
  • @SamHolder and did you try with `git config --global core.autocrlf false` (and making sure there is no `autocrlf` at the local repo level)? – VonC Feb 11 '14 at 13:03
  • @Asenar the poshgit enhancement effectively shows the status `[Branch2 +0 ~3 -0]` shows no files added, 3 files modified, and 0 files deleted. The `git diff --ignore-space-at-eol` shows that these 3 files are only different by spaces at the end of line (I assume) – Sam Holder Feb 11 '14 at 13:04
  • @VonC yes, but this only seemed to change the number of affected files (although I have since realised that it fixed it for files which existed in both branches but not for files which had been deleted in one branch, they still showed as being different) – Sam Holder Feb 11 '14 at 13:07
  • and did you check file permissions ? stderr should tell you if there is a write error or something in .git/ , but maybe for some reason it's not shown – Asenar Feb 11 '14 at 13:09
  • @Asenar if it wasn't able to write the file then the file would be unchanged between branches. The problem can exist when I clone a fresh repo, switch to branchA (no changes reported) then back to master (all of a sudden some files have changed). But I'll check. :) – Sam Holder Feb 11 '14 at 13:18
  • 2
    @Sam Grasping at straws here, but is there a .gitattributes (or .gitignore?) file in one of the branches but not the other (or in both branches, but they are different)? Its usually at the root of the repo, but unfortunately, it could be anywhere in the tree. – Bert F Feb 11 '14 at 13:42

3 Answers3

5

You didn't mention what OS you use, what OS your remote repo uses (if any) or whether your team works cross-platform with other OS's. That kind of info may help diagnose the problem.

I've seen problems like these crop up due to:

  • line-endings (Windows vs Mac vs Linux)

    You fix this with core.*crlf settings and .gitattributes files. The github help page for this and the gitattributes manpage are the great resources for this.

    Trying to fix line-endings with git filter-branch, but having no luck https://help.github.com/articles/dealing-with-line-endings https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

    Don't miss the part at the end of the github help that talks about how you have to normalize your repo after getting this setup:

    After you've set the core.autocrlf option and committed a .gitattributes file, you may find that git wants to commit files that you've not modified. This is because git wants to normalize the line endings for you. The best way to do this is ...

  • case-insensitive filesystems when files/dirs with mismatched case already exist

    In particular, that Src dir looks particularly suspicious to me. This usually happens because someone renamed a file in the repo to the same name but used a different case for one or more letters. Then someone updates their local repo and work dir, git is told by the (case-insenstive filesystem) filesystem that the file/dir already exists, but other git code will treat the file/dir as new.

    Try doing a fresh clone into an new or empty directory. See if the filename/dirname letter cases are different between the paths of the problematic files in your fresh clone and your original clone (look hard at the Src dir - it may be src in the repo. If available, I'd do the fresh clone on a Unix/Linux system.

  • Unicode characters in filenames

    This doesn't seem to be the case for your problem, but I thought it worth mentioning for completeness. This is a variant of the case-insensitivity issue, but is also impacted by how a filesystem handles Unicode characters in filenames.

    See Git clean not removing a file for a description of a problem someone else was having with Unicode in filenames.

Community
  • 1
  • 1
Bert F
  • 85,407
  • 12
  • 106
  • 123
  • Thanks. We are on windows and the remote repo is github. I'll have a read of those links. I'm not sure it anything to do with the casing of the directories as it seems that it can happen to seemingly random files at different times. Once it start to happen with some files it seems repeatable, but once they are fixed later on some other files (which seem not to have been touched) can start to be affected. – Sam Holder Feb 11 '14 at 13:25
  • 1
    @SamHolder Bert F is making a good point here. I faced a similar issue a few years ago due to one person with a case-sensitive FS. It messed up the bare repository, and then developers'. We surely made other mistakes back then (6 years ago...), but the case-sensitive FS was the source of the problem. – Eric Platon Feb 17 '14 at 16:53
1

This problem could be due to line ending preferences in different operation system.

If you are Unix/Mac user then set you config as below

git config --global core.autocrlf input
git config --global core.safecrlf true

If you are on Windows then try config as below

git config --global core.autocrlf true
git config --global core.safecrlf true

After doing these setup, once you switch branches then git status should not complain about anything.

r3b00t
  • 6,953
  • 6
  • 27
  • 37
1

git clean -id should do what you're looking for.

The i will let you verify what gets deleted while the d tells it to remove extra directories as well. Just be careful that it doesn't clean too much and take out anything you want to keep.

Jon
  • 1,398
  • 9
  • 14