Re: problems with clone and .gitattributes

From: Jeff King <peff@peff.net>
Date: Oct 28, 2008, 05:50 UTC
Message-ID: <20081028055058.GB23195@sigill.intra.peff.net>
In-Reply-To: <ee2a733e0810271146r5b21213eg989045e4bf42d99a@mail.gmail.com>

On Mon, Oct 27, 2008 at 02:46:41PM -0400, Leo Razoumov wrote:

> There is a little catch-22 problem here. .gitattributes are stored
> in-tree and git clone does not know about these files existence until
> it checks the tree out, by that time it is already too late to apply
> filters.

Yes, this has been brought up on the list before.

Show 8 quoted lines

> Of course, there could be several obvious workarounds:
> 
> (1) git clone can redo checkout when it finds files affected by gitattributes
> 
> (2) before doing checkout "git clone" inspects tree-object and looks
> for .gitattributes files. If found it checks them out first before all
> other files. Now it can apply the attributes found as the checkout
> process progresses.

I think (2) is closer to the right solution. Though instead of changing checkout order, I think .gitattributes should simply be able to look in an auxiliary tree (and checkout would feed the to-be-checked-out tree to the attribute machinery). One concern, though, is how to handle conflicts between the tree we're moving _to_ and what's already in the working tree. I would think that the tree we're moving to would take precedence.

I feel like Junio may have mentioned some of these issues in a mail the last time this subject came up, but maybe I'm mis-remembering. Try searching the archive.

-Peff