git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [RFR] gitattributes(5) documentation
Date: Thu, 19 Apr 2007 18:45:01 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0704191835290.9964@woody.linux-foundation.org> (raw)
In-Reply-To: <7vslav4yv6.fsf_-_@assigned-by-dhcp.cox.net>


Great. And reading the documentation, something struck me: wonderful docs 
about crlf, but it became clear that either the docs are wrong, or the 
behaviour is less than optimal: you cannot specify "crlf=input" any way?

So I would sugegst that
 - if crlf is set, we still honor the value of "core.autocrlf", we just 
   don't care about the *content*.

Maybe that's what the code is doing (I thought it did, but I'm too lazy to 
check), but the docs don't say that:

On Thu, 19 Apr 2007, Junio C Hamano wrote:
> 
> Set::
> 	A path to which the `crlf` attribute is set is converted
> 	to have CRLF line endings in the working tree upon
> 	checkout, and converted back to strip CRLF line endings
> 	to LF line endings upon checkin.

This documented behaviour is non-optimal for a few reasons:
 - it makes it impossible to say "this is text", and have it work on UNIX 
   platforms ;)
 - it makes it impossible to have "autocrlf=input", and then correct one 
   single file that was incorrectly guessed to be binary, and have that 
   file behave like other files.

So I _think_ the right rules are:

 - unspecified: use autocrlf *and* content detection logic
 - unset: never do crlf<->lf ("binary")
 - set: use autocrlf without content detection logic ("text")

with possibly an added rule:

 - set to value: "true" or "input" force that particular setting 
   *regardless* of autocrlf, ie we'd always get CRLF even on UNIX.

Hmm?

			Linus

  reply	other threads:[~2007-04-20  1:45 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-09  8:17 What's cooking in git.git (topics) Junio C Hamano
2007-04-16  1:53 ` Junio C Hamano
2007-04-19  0:04   ` Junio C Hamano
     [not found]     ` <7vslav4yv6.fsf_ -_@assigned-by-dhcp.cox.net>
2007-04-19  0:23     ` Alex Riesen
2007-04-19  2:39     ` Nicolas Pitre
2007-04-19 10:07     ` Martin Waitz
2007-04-20 11:14       ` Junio C Hamano
2007-04-20 11:58         ` Alex Riesen
2007-04-20 19:31         ` Sam Ravnborg
2007-04-21  6:09           ` Martin Waitz
2007-04-21  7:11             ` Linus Torvalds
2007-04-20  1:29     ` [RFR] gitattributes(5) documentation Junio C Hamano
2007-04-20  1:45       ` Linus Torvalds [this message]
2007-04-20  5:02         ` Junio C Hamano
2007-04-22  0:51           ` David Lang
2007-04-22  7:02             ` Junio C Hamano
2007-04-22  9:33               ` David Lang
2007-04-20  1:57       ` Nicolas Pitre
2007-04-22  6:24     ` What's cooking in git.git (topics) Junio C Hamano
2007-04-23  7:04       ` Junio C Hamano
2007-04-23 16:16         ` Nicolas Pitre
2007-04-23 17:07         ` Alex Riesen
2007-04-23 17:15           ` Junio C Hamano
2007-04-23 21:16             ` Alex Riesen
2007-04-23 21:51               ` Junio C Hamano
2007-04-24 15:58                 ` Alex Riesen
2007-04-24 16:04                   ` Johannes Schindelin
2007-04-24 16:14                     ` Alex Riesen
2007-04-24 16:44                       ` Johannes Schindelin
2007-04-24 21:41                   ` Junio C Hamano
2007-04-25  8:11                     ` Alex Riesen
2007-04-23 17:25           ` Johannes Schindelin
2007-04-27  8:24         ` Junio C Hamano
2007-04-29 18:33           ` Junio C Hamano
2007-04-29 18:45             ` Linus Torvalds
2007-04-30 23:20               ` Junio C Hamano
2007-05-06  8:53             ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.98.0704191835290.9964@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).