Hi, On Fri, 28 Mar 2008, Jakub Narebski wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
