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

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 28, 2008, 13:02 UTC
Message-ID: <m3bq4zuhn5.fsf@localhost.localdomain>
In-Reply-To: <alpine.LSU.1.00.0803281321260.18259@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 16 quoted lines

> On Fri, 28 Mar 2008, Toby Corkindale wrote:
> 
> > 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?
> 
> The problem is that "git archive --remote" operates on the remote 
> repository as if it were bare.  Which in many cases is true.
> 
> So I'd submit that this is not the usage .gitattributes is meant for, and 
> that you should clone the thing if you want to generate archives heeding 
> the .gitattributes.

This is simply caused by lacking implementation of .gitattributes (which is quite new feature, so it is somewhat understandable).

As I see it nothing prevents git to take and use .gitattributes from a given tree (from a top tree of a given commit)... well, nothing except the fact that git-check-attr, and probably also API used by attributes code in builtins, doesn't have place to provide blob to be used as .gitattributes (or tree to take .gitattributes from).

-- 
Jakub Narebski
Poland
ShadeHawk on #git