Michael J Gruber wrote: > 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. I agree. > > 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. Yes, that is a problem. Ideally, the crlf attribute would be tied to the file entry itself rather than a separate file (so changing the attribute would mean a change to the file), but I guess we are stuck with what we have. I still think that case 2) is the most common, and fixing it has the appealing property that if the repository line endings are broken for some reason (because of case 1 or something else), then recloning or checking out from scratch is guaranteed to bring the working tree into the "correct" state. Since fixing both cases is a pretty big task and fixing only case 2 is small, I propose that we go ahead with that. -- Kristian Amlie -- 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
