problems with clone and .gitattributes

Leo Razoumov· Oct 27, 2008, 18:46 UTC · lore

Hi Everyone, I am using .gitattributes with clean/smudge filters to optimize storage of OpenOffice binary files (zip compressed). So far it works fine except for clone operation. Apparently, "git clone" does not call smudge filter when checking out a branch. I have to manually remove openoffice files and then do "git co -f" to re-checkout them again, this time smudge filter gets applied.

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.

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.

IMHO, both workarounds are somewhat clumsy. Is there anything cleaner that can be done to solve the problem?

--Leo--

Jeff King· Oct 28, 2008, 05:50 UTC · re: Leo Razoumov · lore

Re: problems with clone and .gitattributes

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