Re: Surprising interaction of "binary" and "eol" gitattributes
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 11, 2015, 21:31 UTC
- Message-ID
- <xmqq7fun5ih6.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <5500A5F7.1000503@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
Show 22 quoted lines
>> I would say former. You find out what attributes apply to a path >> and then consider the collective effect of these attributes that >> survived. >> >> So the second "No it is not text" which is overruled by the "oops, >> no that is text" later should not get in the picture, I would say. >> >> As binary is not just -text and turns other things off, those other >> things will be off after these three. > > Is that how attribute lookup works? I.e., given a path, all attributes > are collected? > > 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.