Kristian Amlie venit, vidit, dixit 28.01.2009 16:25: > 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 -- 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
