Re: [RFR] gitattributes(5) documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

David Lang <david.lang@xxxxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]