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