[BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)

[Toby Corkindale <toby.corkindale@rea-group.com>]

Jeff King wrote:
> On Thu, Mar 27, 2008 at 03:48:31PM +1100, Toby Corkindale wrote:
> 
>>> I vaguely recall some discussion of this in the past, so maybe it isn't
>>> a good idea. But I would think changing git-archive to respect
>>> .gitattributes might be worth doing (presumably the version of
>>> .gitattributes from the tree that is being exported).
>> Respecting the repo's .gitattributes would feel right. It seems unusual  
>> (to me) that it bypasses $REMOTE/.gitattributes, but DOES check  
>> $REMOTE/info/attributes.
> 
> I agree that it seems like a bug. You might search the list archives for
> discussion around the export_subst attribute to see if it was discussed
> then or if it is simply an omission.

My searches haven't turned anything up that seems relevant.
I submit that this is a bug, or at least undesirable behaviour:

"git-archive --remote=/some/repo" will ignore /some/repo/.gitattributes, 
but check /some/repo/info/attributes.

I think the problem is in the loop that looks for .gitattributes, which 
seems to do so by taking the current path and iterating down through it?
In the case of remote archives, shouldn't that start by taking the path 
of the repo, not current dir?

Or should it go one step further, and check the .gitattributes for every 
file it extracts? That is the behaviour you get if you run git-archive 
from within a repo, rather than remotely - and don't we want that to be 
consistent with using --remote?

ie. I'm thinking of structures like:
/myModule/testfile.pm
/myModule/subdir/testfile.pm
/myModule/subdir/.gitattributes

if I do "cd /myModule; git-archive HEAD" then shouldn't I get the same 
output as if I did "cd /tmp; git-archive --remote=/myModule HEAD" ?