Re: Surprising interaction of "binary" and "eol" gitattributes
- From
Torsten Bögershausen <tboegi@web.de>
- Date
- Mar 11, 2015, 05:54 UTC
- Message-ID
- <54FFD89A.9050306@web.de>
- In-Reply-To
- <xmqqsidcxy2q.fsf@gitster.dls.corp.google.com>
On 03/10/2015 11:54 PM, Junio C Hamano wrote:
Show 22 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes: > >> Well, that's true, but the "eol" attribute can regain its effect if >> "binary" is followed by "text" or "text=auto". So I guess the simplest >> question is as follows. Suppose I have the following .gitattributes: >> >> a.foo eol=crlf >> a.foo binary >> a.foo text >> >> It is obvious in this case that a.foo should be treated as a text file. >> Should it be processed with "eol=crlf", or should the intervening >> "binary" imply "-eol"? > 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.
Not sure if I follow: Whenever you specify -text, the eol doesn't matter, or what do I miss ?
Specifying "*.txt eol=crlf" includes "*.txt text", but with the following it should be possible to turn on "text=auto"
cat .gitattributes * eol=crlf *.sh eol=lf * text=auto *.png -text