From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
"git discussion list" <git@vger.kernel.org>
Subject: Re: Surprising interaction of "binary" and "eol" gitattributes
Date: Tue, 10 Mar 2015 23:16:03 +0100 [thread overview]
Message-ID: <54FF6D23.4060301@alum.mit.edu> (raw)
In-Reply-To: <xmqq385c1v13.fsf@gitster.dls.corp.google.com>
On 03/10/2015 09:01 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> [...]
>> It seems to me that setting "text=auto" should mean that Git uses its
>> heuristic to guess whether a particular file is text or not, and then
>> treats the file as if it had "text" or "-text" set. If the latter, then
>> EOL translation should be suppressed.
>
> ... I think this makes even more sense. I do not think the code is
> set up to do so. To be honest, eol_attr thing introduced in
> fd6cce9e (Add per-repository eol normalization, 2010-05-19) always
> confuses me whenever I follow this codepath.
Would this change be "backwards-compatible enough" that it can be made
without waiting for Git 3.0?
>> It also seems to me that "binary" should imply "-eol".
>
> I thought that "eol" attribute is not even looked at when you say
> "binary"; that is what I recall finding out when I dug into this
> earlier in the thread.
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 guess it would be more natural to process it with "eol=crlf". So I
withdraw my proposal that "binary" should imply "-eol", provided the
first change (that "text=auto" is treated the same as "-text" for binary
files) is implemented.
So I guess the proposed new behavior WRT these attributes is:
* "text" determines whether a file should be subject to EOL
translation.
* "text=auto" has the same effect as "text" or "-text", depending
on the outcome of the binary detection heuristic; in particular,
it causes EOL translation to be suppressed for files determined
to be binary.
* "eol" determines what EOLs should be translated to *if* the
file is determined to be a text file.
* If "text" is unspecified but "eol" is specified, then do EOL
translation without a heuristic check.
But I still have to work out how core.autocrlf and the "crlf" attribute
fit into all this.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
next prev parent reply other threads:[~2015-03-10 22:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 16:38 Surprising interaction of "binary" and "eol" gitattributes Michael Haggerty
2015-03-05 20:49 ` Torsten Bögershausen
2015-03-05 22:08 ` Junio C Hamano
2015-03-06 5:59 ` Torsten Bögershausen
2015-03-06 17:51 ` Michael Haggerty
2015-03-06 21:30 ` Torsten Bögershausen
2015-03-10 19:25 ` Michael Haggerty
2015-03-10 20:01 ` Junio C Hamano
2015-03-10 22:16 ` Michael Haggerty [this message]
2015-03-10 22:54 ` Junio C Hamano
2015-03-11 5:54 ` Torsten Bögershausen
2015-03-11 17:59 ` Junio C Hamano
2015-03-11 20:30 ` Johannes Sixt
2015-03-11 21:31 ` Junio C Hamano
2015-03-11 21:43 ` Junio C Hamano
2015-03-10 20:26 ` Torsten Bögershausen
2015-03-10 22:24 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FF6D23.4060301@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.