On Sat, Apr 9, 2011 at 11:32 PM, Jeff King <peff@xxxxxxxxxx> wrote: > > I just wonder if git can do better. But the only options I could think > of are: > > 1. Set the working tree file to have just LF's. But that doesn't help, > since it is the conversion _to_ linefeeds that make it look like > the file is changed. So we'd still see unstaged changes. Well, eol=crlf _does_ set the working tree file to have only CRLF, but you still have the same race as before. Just because git converts file, it does not think about it as "dirty". It becomes "dirty" when git tries to convert it back and gets a different result, and whether it tries or not depend on timestamp. So, you still have the same race. >> > So we get two different outcomes, depending on the index raciness. Which >> > one is right, or is it right for it to be non-deterministic? >> >> I like everything being deterministic, but in this case I do not see >> how it is possible without making the normal case much slower. > > I think if you took my (1) suggestion above, it would be deterministic. Replace "eol=lf" with "eol=crlf" in your script, and you will see that it does not help with the race. > > I absolutely agree, and my first advice upon seeing this jquery repo was > to fix those line endings. But they went for over a year with the broken > setup, so clearly it wasn't bothering them. I wonder what git could do > better to provoke them to fix it sooner. I believe git should consider all files as "dirty" if .gitattributes is changed. So, you cannot accidentally commit changes to .gitattributes without fixing line endings. Currently, you can provoke git to consider all files as dirty by doing: touch -d 2000-1-1 .git/index but we should not expect users to do that after editing .gitattributes. Dmitry -- 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