Re: [RFR] gitattributes(5) documentation

[David Lang <david.lang@digitalinsight.com>]

On Sun, 22 Apr 2007, Junio C Hamano wrote:

> David Lang <david.lang@digitalinsight.com> writes:
>
>> in the long run this would let you phase out the core.autocrlf option
>> entirely, letting the bahavior be specified in gitattributes.
>
> You _could_, but that is quite against what we want.  These
> should stay separate, and the gitattributes mechanism is
> designed specifically to allow them cleanly separated.
>
> The configuration "core.autcrlf" describes a particular
> repository.  If the platform the repository is on expects text
> files to be line-terminated with CRLF, you would have
> core.autocrlf set; otherwise you don't.
>
> On the other hand, gitattributes' 'crlf' describes if the path
> is text, and that is the reason it can and should be "in-tree",
> i.e. not just $GIT_DIR/info/attributes (which is private to the
> repository) but in .gitattributes (and subdirectories'), which
> is given to everybody who has a copy of the project.

I was thinking that it should be in $GIT_DIR/info/gitattributes along with the 
rest of the crlf defintitions.

> How text files are handled is a local matter, and stays in the
> config.  Which ones are text is the same for everybody who has a
> copy of the project, and is in-tree information.

I understand what you are aiming for, but you are depending on people doing the 
defining of what files are text in the .gitattributes files instead of 
$GIT_DIR/info/gitattributes, which is also valid to do with things as currently 
defined (at least if I'm understanding them correctly)

what you really do want for crlf is one variable that, if set, uses the value of 
another variable.

i wonder if this is useful enough to define formally. something along the lines 
of
[default] crlf=input
in the $GIT_DIR/info/gitattributes file

at the moment we have crlf (set by core.autocrlf) and merge (set by the 
environment variable), I think I saw that it may also be possible to define a 
different diff to use by default as well (possibly by useing a third method to 
define the default, possibly by an environment variable, I don't remember)

if you could set the defaults in the $GIT_DIR/info/gitattributes file and then 
have the flag set/unset/set-to-value in the whatever gitattributes file(s) are 
appropriate, it would consolodate the configurations into one related place 
rather then spreading them around with different ways to set the defaults for 
different things.

David Lang