Re: Unresolved issues

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 21, 2007, 00:21 UTC
Message-ID: <Pine.LNX.4.64.0702201621050.4043@woody.linux-foundation.org>
In-Reply-To: <7vfy90v729.fsf@assigned-by-dhcp.cox.net>

On Tue, 20 Feb 2007, Junio C Hamano wrote:

Show 5 quoted lines

> >
> > 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