It was the CRLF conversion. When I played around with git config --global core.autocrlf true/false I got the problem to eventually go away. Thanks for all your responses. > > On Tue, Nov 4, 2008 at 8:21 PM, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: >> >> On Mon, 3 Nov 2008, Andrew Arnott wrote: >> >> > I was just git commit'ing, and then I was doing a git rebase to squash >> > several commits into one when the rebase failed. I then did a >> > git checkout -f master >> > git reset --hard >> > but no matter what I do, git thinks that several files have changed. >> > The diff shows all the lines in these several files removed and then >> > added, yet without any changes made to them. >> >> That sounds like some failure of CRLF conversion, like it's converting all >> of the line endings somehow when writing to the working tree and then not >> expecting them to be different. Do you have some sort of interesting >> configuration for those? I wonder if you've got a .gitattributes that >> matches the names that git uses for the files, but are on a >> case-insensitive filesystem which lists those files in a way where their >> names don't match (or vice versa). >> >> -Daniel >> *This .sig left intentionally blank* > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
