Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> 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.
Let alone the case where you need to merge .gitattributes file
itself and the conflicting part says something conflicting about
other paths that needed to be merged and the result need to be
checked out ;-).
> 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.
Yes. That is what I had in mind when I said "initial checkout".
> 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
And git-apply which is (as usual) on its own.
-
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