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" ?
--
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
