Re: Honoring a checked out gitattributes file

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jan 28, 2009, 16:44 UTC
Message-ID: <49808B53.6040907@drmicha.warpmail.net>
In-Reply-To: <498078F1.20807@trolltech.com>

Kristian Amlie venit, vidit, dixit 28.01.2009 16:25:

Show 22 quoted lines

> Hi!
> 
> We currently use msysGit in our company test farm to checkout the latest
> development branch and do autotests. However, we have one problem:
> Certain files require UNIX line endings, even though this is a Windows
> system. For this we use .gitattributes.
> 
> However, if the .gitattributes file is also checked in to the branch, it
> will not always be honored. I browsed the code a bit, and it seems to
> happen whenever there is an existing .gitattributes file, but the
> checkout adds new files to it. These new files will not get the correct
> line endings (although I'm not sure if it happens *every* time, it could
> depend on the order they are checked out).
> 
> I think this should be fairly straightforward to fix, by ensuring that
> if there is a file called .gitattributes in the index of the current
> directory, check it out first, before all the other files that may be
> affected by it. I can produce a patch and testcase for it, but I wanted
> to hear the opinions of some developers in case there is an obvious flaw
> in my solution.
> 
> What do you think?

I think there's a general time ordering problem. Say you do the following commits:

A: add a.txt
B: add a .gitattributes file covering *.txt (say with crlf or any filter)
C: add c.txt

Now, with an empty dir, you do either

1) checkout A, B, C sequentially
2) checkout C

The contents of the checkout will be different in cases 1) and 2):
1) a.txt is checked out out as is, c.txt according to the attributes
2) with current git: probably like 1), with your suggestion: both a.txt
and c.txt filtered according to the attributes.

If you add a file and .gitattributes covering it in the same commit there is an ordering ambiguity which can be solved (patched away) easily, but I think the difference between 1) and 2) is still problematic, and would need to be dealt with.

The main problem seems to be that changing a file like gitattributes can potentially change (by changing filters) the contents which should be stored for a different file even if the checkout of that file doesn't change.

Cheers, Michael