Re: [PATCH v2 0/2] Improvements to tests and docs for .gitattributes eol

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 16, 2022, 10:28 UTC
Message-ID: <YgzRyKZwsPw6rTyT@camp.crustytoothpaste.net>
In-Reply-To: <9ce63b16-cf75-3404-88cf-0623194db07b@kdbg.org>

On 2022-02-16 at 07:00:24, Johannes Sixt wrote:

Show 17 quoted lines

> Just so you know where my confusion arises from: Your updated text has
> the structure (as I read it)
> 
>    if ... set or unspecified or if auto then ... detected ... and LF
> 
> It is unclear whether the 'then' conditions apply only to 'if auto'.
> Even if the additional 'if' in the middle makes me think that the
> 'then's apply only to the 'auto' case, it is sufficently vage because in
> my mental model there is not much difference between an 'unset' and a
> set-to-'auto' attribute, and I wonder why the 'then's should not apply
> to the 'unset' case as well.
> 
> Moreover, after re-reading the text, I notice that text may be read as
> "this attribute has an effect only if <conditions>" where <conditions>
> basically means "always except for when the 'if auto' case is not met",
> right? Would it perhaps be better to write "has no effect if <very
> specific condition>"?

The situation is that eol is in effect if and only if:

* text is set;
* text is unspecified; or
* text is auto, the file is detected as text, and the file has LF line
  endings in the index.

Alternately, it has no effect if and only if:

* text is unset;
* text is auto and the file is detected as binary; or
* text is auto and the file is detected as text and has CRLF line
  endings.

I'm not sure one reads significantly easier than the other. I slightly prefer the former because it has fewer conditions with multiple nested entries, though.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA