Re: Surprising interaction of "binary" and "eol" gitattributes

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2015, 21:43 UTC
Message-ID: <xmqq385b5hwu.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqq7fun5ih6.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 16 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
>
>> Isn't it more like: Here we are interested in the "eol" attribute of
>> this file named "a.foo". And the lookup would find the first line that
>> says "eol=crlf". Elsewhere, we are interested in the "binary"
>> attribute of the file named "a.foo", and lookup would find the second
>> line that sets the "binary" attribute. And again elsewhere, we ask for
>> the "text" attribute, and we find the last line that sets the "text"
>> property.
>>
>> Am I totally off track?
>
> In the codepath in question, we say "we are interested in text and
> eol attributes", grab the values (set/unset/set-to-value/unspecified)
> for these two for the path we are interested in from all the
> applicable gitattributes file and then act on the result.

Technically the above is only a half-answer; I know you are intelligent enough to derive the other untold half from it, but for the benefit of those reading from sidelines....

The calling convention to (1) prepare the list of attributes you are interested in upfront and then (2) to ask the set of attributes that apply among that set for a path is designed to force programmers avoid doing attribute lookups (which is rather expensive) at random places in their code. But in the end, this let us implement the functionality as you alluded to in the quote paragraph.

If a proposed change wants to make 'text=auto' stronger in the sense that we decide if we pay attention to 'eol' only after checking if the contents look non-text, it can do so, just like setting '-text' to the current code makes settings of 'eol' irrelevant.