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