git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).