Re: Unresolved issues

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

On Tue, 20 Feb 2007, Junio C Hamano wrote:
> >
> > 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.
> 
> Except for the initial checkout...

Yeah, that's true. That's indeed pretty nasty.

There's also a rather strange special case when you do merges: you can 
certainly always use the .gitattributes of the working tree, but it will 
cause some interesting issues if new files were added with new patterns.

However, we're a bit lucky here (or perhaps "lucky" is not the right word: 
we basically have a good design) where all these actions come down to "git 
read-tree", regardless of whether it's checking out the end result of a 
totally new clone, or a fast-forward update, or a merge. Or a "git 
checkout" or "git reset". They all boil down to one thing:

	git read-tree -u

and it should be fairly easy to add some simple logic just to 
"cmd_read_tree()" to do the right thing. It has the "main tree" to use, 
and the logic could be as simple as

	fd = open(".gitattributes", O_RDONLY);
	if (fd < 0) {
		.. try in "$tree:.gitattributes" instead ..


and it would do the right thing for all the common operations.

Again, the special case (as always) is
 - git cat-file
 - the file-level merger code (which uses the equivalent of git-cat-file)
which would need to add their own logic for this.

		Linus