From: Toby Corkindale Date: Fri, 28 Mar 2008 05:10:41 GMT Subject: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned) Message-ID: <47EC7DD1.3060102@rea-group.com> In-Reply-To: <20080327045342.GC6426@coredump.intra.peff.net> 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" ?