CRLF support bugs (was: Re: .gitattributes glob matching broken)

From: Hannu Koivisto <azure@iki.fi>
Date: Nov 3, 2008, 15:05 UTC
Message-ID: <83y700alzf.fsf_-_@kalahari.s2.org>
In-Reply-To: <20081103090932.GA18424@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> I think your analysis is incorrect. I will try to explain what is
> happening.

Yes, you are right. The behaviour I saw in my actual use case was so odd that I got completely confused.

I suspect one part of that "oddness" was caused by git applying its heuristics in checkout as it doesn't use .gitattributes at that time. For example, it seems that it recognized some of my .sh files as text files and the rest as binary files. I suppose I was correct to assume that it would be stupid to rely on git guessing file type and the only sensible way is to use .gitattributes. If it was supported in checkout too, that is.

I don't know what purpose the autodetection aims to serve but I'd add a big warning in the core.autocrlf documentation about it and instructions on how to configure things so that it is never applied but instead the types must always be specified explicitly.

Show 7 quoted lines

> The problem, again, is that we have inconsistently applied the
> gitattributes. They were _not_ applied during checkout (because
> .gitattributes did not exist yet), but they _are_ being applied here.
>
> To "fix" this, you can then do a "git reset --hard" which will respect
> your .gitattributes (since it is now checked out). And further file
> creation and checkout should work OK.

Since I'm trying to launch git in a company environment, I think I can't rely on people remembering to do that.

Actually, even if .gitattributes were applied in checkout, I think the whole CRLF support is broken by design because people will have to remember to use -n in clone, then enable core.autocrlf support and then checkout. This makes it unneccessarily complicated to create "quick local clones" as well. You might suggest that Windows users should enable core.autocrlf globally but it may not be the right thing to do for all projects/repositories either.

I think CRLF conversion support should have some attribute (be it .gitattributes attribute or something else) that is somehow inherited from the parent repository. It would basically say that "you should use platform's native line end type for text files with this repository and its children". To go with that, one would maybe have a configuration option to tell what that platform default line end type is (just in case someone wants to pretend Cygwin is Unix or something like that).

I also observed this problem:

# Pretend someone does this on Unix mkdir test1 cd test1 git init echo "*.c crlf" > .gitattributes echo -en "foo\r\nfoo\r\nfoo\r\n" > kala.c git add .gitattributes kala.c git commit -m "* Initial checkin." cd .. # Pretend someone else does this on Windows git clone -n test1 test2 cd test2 git config core.autocrlf true git checkout git status

... # modified: kala.c ...

git reset --hard git status ... # modified: kala.c ...

Now, even if .gitattributes were obeyed by checkout, I suspect the end result would be the same(?) I'm sure someone argues that this makes sense. But try to put yourself in the position of a random Window user. I think it's far from obvious what is going on and what should be done in this situation.

-- 
Hannu