Štěpán Němec [off-list ref] writes:
quoted
Hello,
it seems there is no global .gitattribute equivalent to .gitignore or
.gitconfig. Wouldn't it make much sense to have one? Failing that, there
really should be a way to specify some global diff options at least.
I'd like this feature too. My use-case is to have antiword and odt2txt
as textconv filters for .doc and .odt files, which I always want to
do. But probably the feature won't get implemented until one of us
writes a patch ;-) (I may have time later, but not before a few
days/weeks).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Matthieu Moy venit, vidit, dixit 26.04.2010 15:48:
Štěpán Němec [off-list ref] writes:
quoted
quoted
Hello,
it seems there is no global .gitattribute equivalent to .gitignore or
.gitconfig. Wouldn't it make much sense to have one? Failing that, there
really should be a way to specify some global diff options at least.
I'd like this feature too. My use-case is to have antiword and odt2txt
as textconv filters for .doc and .odt files, which I always want to
do. But probably the feature won't get implemented until one of us
writes a patch ;-) (I may have time later, but not before a few
days/weeks).
I leave it up to you to do the (re)search, but there's some preexisting
patches and discussion around this topic. The upshot is that currently:
SYSTEM | GLOBAL | VERSIONED | LOCAL
$(prefix)/etc/gitconfig | $(HOME)/.gitconfig | N/A |
$(GIT_DIR)/config
N/A | N/A | .gitattributes (rec.) |
$GIT_DIR/info/attributes
N/A | N/A | .gitignore (rec.) |
$GIT_DIR/info/exclude
There's also GIT_CONFIG overriding the defaults, and core.exludesfiles
(yes, with s!); and of course command line parameters.
There's been requests for versioned config, for multiple sources of
system config (think config.d/*), for global and system versions of
attributes and exclude/ignore, for saner naming of exclude(s) vs.
ignore, and, finally, for stopping all this madness, or rather: putting
all of it in a subdir, aptly named gitconfig... no-no, no-go... or
following the XDG conventions, or...
So, you see: You may suggest something simple like core.attributesfile.
I have a prediction how that goes.
But now, right after 1.7.1, it might be a good time to really settle
this in a future-proof yet backwards-compatible way.
Michael