On 23. mai 2010, at 00.27, Clemens Buchacher wrote: > Hi Eyvind, > > Thanks for the extended summary. I still have several doubts, as > detailed below. But I understand that this has been heavily > discussed and if the discussion has indeed come to a conclusion, > then I will not complain about it now. I appreciate your comments. The more people who take a critical look at the series, the better :) I think most of your concerns were covered during the discussion, but it's always good to have more sanity checks. [...] > For all my comments below I am assuming that the behavior of > autocrlf will be changed to respect the crlf/text attribute by > default. That's right, the attribute is used regardless of what autocrlf is set to. >> The "eol" attribute is used for files that need a specific line >> ending. Setting it also sets "text". > > If a file needs specific line endings, why enable conversion for > this file at all? Just make sure the repository contains the > correct version and unset the crlf attribute. Yeah, that's what I initially thought too, but it makes sense to be able to use normalization to prevent line ending breakages in your repository. If a file needs CRLFs for some tool to work, you don't want anyone to inadvertently convert it to LF, and "eol=crlf" makes git enforce that. [...] >> There is a backwards compatibility wrinkle in that core.autocrlf >> will override core.eol if the latter isn't explicitly set, so >> that "core.autocrlf=true" still results in CRLFs in the working >> directory on Linux. > > This also makes sense. I just fear that making this frequently > misunderstood feature even more complex will only confuse users > further. I agree, but I really wanted to avoid breaking any settings. I'm thinking of submitting a patch to remove the backwards compatibility for 1.8, leaving core.autocrlf as a simple boolean meaning "* text=auto". > I do see the value of a global core.eol option, however, since it > allows me to convert to LF instead of CRLF, which AFAIK is not > currently possible. Actually, since git normalizes to LF, "eol=lf" simply means "convert on input but not on output", which is what "core.autocrlf=input" currently does. The fact that you didn't know this reflects the poor usability of core.autocrlf, which is one of the things this series is trying to rectify :) It also allows for the possibility of supporting other line endings such as the classic Mac "CR only". That might not be a good thing. > On the other hand, this will cause users to stop caring whether or > not a file in the repository has LF or CRLF line endings. I am not > sure if that is a good thing, but I suppose it is better than what > we have now. The problem is that users don't care anyway, and they've been trained by other VCSes that they shouldn't need to care. This series allows me to put "* text=auto" in my repository and git will automatically normalize text files regardless of the user's configuration, which wasn't possible before. [...] > I see. Well, if we rename the "crlf" attribute then we will have a > macro attribute "binary" and an attribute "text", which are not the > opposite of each other. That is a bit strange. Yes, but I don't think it should cause any problems in practice. Since the "binary" attribute just means "-text -diff" it will override a "* text=auto", which I is the only relevant interaction I can see. -- Eyvind -- 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