Hi, On Wed, Dec 16, 2009 at 6:24 AM, David Antliff <david.antliff@xxxxxxxxx> wrote: > I suspect what is happening is that the line conversion routine in git might be > stripping trailing whitespace, as well as converting the line endings. This > operation is not properly accounted for in the reverse direction, and the file > is flagged as modified. I am not a Git expert, but could it be your editor on Windows? Not just stripping whitespace; it might be setting the eol to LF (instead of CRLF) when saving the file. > Also, as cloned files are converted to DOS-line-endings, by default Cygwin's > bash cannot run any scripts as they have the wrong line endings. I have to set > the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash scripts > can run. Perhaps this is wrong and git on Cygwin (with binary mounts) should be > converting to UNIX line endings instead? Again, IANAGE, but according to the manual, this should be expected, because Git, when writing to the filesystem, converts LF to CRLF: If true, makes git convert CRLF at the end of lines in text files to LF when reading from the filesystem, and convert in reverse when writing to the filesystem. > At one point I tried switching off core.autocrlf for myself but this caused a > lot of conflicts due to mismatched line-endings. It seems to me that if we want > to switch to this, *everyone* has to do it at once. Just make this conversion a commit, and depending on your project's workflow, push/pull it. Although the whole file will be marked as changed, you can always double-check that only whitespace changes have been made by running git-diff with --ignore-space-at-eol or -b. -- Cheers, Ray Chuan -- 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