Re: Unresolved issues

> 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