problems with clone and .gitattributes

problems with clone and .gitattributes

[Leo Razoumov]

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

Re: problems with clone and .gitattributes

[Jeff King]

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.

> 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