Hi,

On Fri, 28 Mar 2008, Jakub Narebski wrote:

quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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).

Of course, you can ask for people to patch it.  Or even provide a patch 
yourself.  Personally, I do not think it is worth it.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html