David Lang [off-list ref] 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.
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.
On Sun, 22 Apr 2007, Junio C Hamano wrote:
David Lang [off-list ref] writes:
quoted
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