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

[Hannu Koivisto <azure@iki.fi>]

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.

> 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