The repos that exhibit this behavior are Visual Studio projects and the 
problem files are text files.

I don't think the problem is line endings. git diff returns nothing and the 
projects have * text=auto in the .gitattributes file and core.autocrlf set 
to true.

I believe the problem is caused by Visual Studio. This never happens on any 
project that doesn't use it. But I don't know what it's doing to the files.

What I'm most confused by is why doesn't git checkout or git reset --hard 
the problem. Why do I have to delete the .git\index for git to properly 
recreate these file?

On Wednesday, February 24, 2016 at 10:03:24 AM UTC-6, Dale R. Worley wrote:
> Ben Page < <javascript:>> writes: 
> >>git status 
> > On branch master 
> > Your branch is behind 'origin/master' by 2 commits, and can be 
> > fast-forwarded. 
> >   (use "git pull" to update your local branch) 
> > Changes not staged for commit: 
> >   (use "git add <file>..." to update what will be committed) 
> >   (use "git checkout -- <file>..." to discard changes in working 
> directory) 
> >         modified: XXXXXXX 
> >         modified: YYYYYYY 
> > no changes added to commit (use "git add" and/or "git commit -a") 
> Certainly one thing you can do is "git diff XXXXXX" and see what Git 
> thinks the changes are. 
> Unfortunately, I don't know if git-diff is completely rigid about 
> reporting different ends-of-lines.  You can 
>     mv XXXXXX XXXXXX.old 
>     git reset --hard 
>     diff XXXXXX XXXXXX.old 
> if you know that the diff you are using reports all byte differences. 
> As the other responder said, the underlying cause is likely file name 
> casing or ends-of-lines, which are the sort of things that get 
> translated between files in the working directory and the repository. 
> Dale 

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to