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

[Junio C Hamano <gitster@pobox.com>]

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

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