Thanks, I think it must have been a bug - I realized that even though I thought I was on the latest git, I had an older copy hiding in my path; once I upgraded the problem went away. On Thu, Jan 20, 2011 at 2:54 AM, René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> wrote: > Am 17.01.2011 20:56, schrieb Graham Sanderson: >> Apologies if someone has answered this before: >> >> So we have moved some big teams over to git (awesome thx), and have >> been using the msysgit default core.autocrlf=true on Windows, and >> making sure text files are LF on other platforms >> >> However we do continue to have a few problems with people storing CRLF >> in the repository (partly because of lack of understanding, and partly >> it seems because of eGit on windows which ignores core.autocrlf). >> >> Anyway, this much is all fine, and we can fix; what I don't understand >> is why for files stored as CRLF in the repository it seems >> indeterminate when or if they show up locally modified (on my window >> box with core.autocrlf = true) when I pull them from the repository. I >> assume the idea is that that they "would be" modified if I were to >> check them in, since they would be converted to LF, however this only >> happens sometimes and for a seemingly random subset of the files >> stored incorrectly. >> >> It also seems to depend on the state of the local index, as recreating >> the local index often changes the set of files that are displayed this >> way (even without any changes to the files), and it also seems to be >> different on different machines (perhaps based on when they happened >> to pull code). >> >> If anyone can give me a quick mental picture of how this is supposed >> to work (i.e. at what time the eol conversions are considered) then >> that'd be great... otherwise I guess I'll go dig in the code. > > Perhaps this recent thread is of interest to you, even though it's on a > slightly different topic and inconclusive: > > http://thread.gmane.org/gmane.comp.version-control.git/163794 > > It would be nice to have the expectations in your case codified in a > test script -- based on the documentation, if possible. > > René > -- 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