Re: Unresolved issues

[Linus Torvalds <torvalds@linux-foundation.org>]

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