Re: What's cooking extra
On 23. mai 2010, at 00.27, Clemens Buchacher wrote:
Show 6 quoted lines
> 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.
Show 6 quoted lines
>> 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.
[...]
Show 8 quoted lines
>> 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
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>