On Mon, 19 Feb 2007, Junio C Hamano wrote:
>
> * core.autocrlf
>
> What's still missing is support for .gitignore like "these files are
> text" information.
Well, we could actually just do that in stages.
We might start off with just saying "unlike .gitignore", we only support
one top-level ".gitattributes" file. That makes the problem space much
simpler, and then we can have code like
enum file_type {
FILE_AUTO,
FILE_BINARY,
FILE_TEXT
};
static enum file_type get_file_type(const char *pathname)
{
static int has_initialized = 0;
if (!has_initialized) {
has_initialized = 1;
read_file_attributes_file();
}
... check the filename against our attribute rules ..
}
which would be fairly straightforward, and efficient.
It gets more complicated with per-directory attributes files, because then
you need to either open those files *all* the time (stupid and expensive
if you have thousands of files and hundreds of directories), or you need
to have some way to cache just the ones you need.
(In fact, it might be perfectly fine to have just a *single* cache, which
is keyed on the dirname of the pathname: if the dirname changes, just
throw the cache away, and read it in from all the subdirectories leading
to that directory - you'd still re-read stuff, but all the common cases
will walk the directory structure in a nice pattern, so you'd have a very
simple cache that actually gets good cache hit behaviour)
> One thing that might be tricky is what should be done while making a
> merge or checking out from a tree. Ideally, the information should be
> read from the tree that is being extracted, but that would make the
> code structure a little bit, eh, "interesting".
No, that would be pretty horrid. So just tell everybody that it's based on
the working tree. I don't think it's likely to be a problem in practice.
Linus
-
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