EOL strangeness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,

Graham.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]