On Tue, Sep 1, 2009 at 8:46 AM, <david.hagood@xxxxxxxxx> wrote: > I am having a problem trying to support my poor, deluded cow-orkers who > use Windows and need to use GIT. > > The scenario goes something like this: > > They have a local repo, they have changes on their branch, they are > staging a commit to the master branch on their local. > > They do a "git merge" and the merge has conflicts. They need to undo the > merge, so they do a "git reset --hard". > > From that point onward, if they try to access the origin repository (e.g. > "git pull") they get the error message > > Error: Entry "Some file name" not uptodate: cannot merge. > > We've tried "git reset --hard; git pull ." We've tried "git reset --hard; > git checkout -f master". Neither seems to fix this. > > We Linux users don't see this. > > I conjecture it is something to do with DOS's CR/LF line endings (the > files in question are a type of XML file which ALWAYS have CR/LF endings, > even under Linux) - perhaps *something* in the GIT processing chain is > trying to do a CR/LF -> LF conversion, and screwing things up. > > Does anybody have any suggestions on what I am doing wrong (Please, not > "you are using Windows")? Yeah I run into the same thing on Windows if somebody accidentally checks in a CRLF file. Do you have core.autocrlf on? If you do, I think the problem is that it's going to try to convert the line endings on every checkout/etc, but since the file is already CRLF (not LF as is normally in the repository), it's going to make the file look different every time. It seems like you want core.autocrlf to be false or you want a .gitattributes file to override it on a per-file basis for the files you know are CRLF (i.e. the ones that are CRLF even on the Linux side). -- 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