Re: [RFH] eol=lf on existing mixed line-ending files

[Dmitry Potapov <dpotapov@gmail.com>]

On Sat, Apr 9, 2011 at 11:32 PM, Jeff King <peff@github.com> wrote:
>
> I just wonder if git can do better. But the only options I could think
> of are:
>
>  1. Set the working tree file to have just LF's. But that doesn't help,
>     since it is the conversion _to_ linefeeds that make it look like
>     the file is changed. So we'd still see unstaged changes.

Well, eol=crlf _does_ set the working tree file to have only CRLF, but
you still have the same race as before. Just because git converts file,
it does not think about it as "dirty". It becomes "dirty" when git
tries to convert it back and gets a different result, and whether it
tries or not depend on timestamp. So, you still have the same race.

>> > So we get two different outcomes, depending on the index raciness. Which
>> > one is right, or is it right for it to be non-deterministic?
>>
>> I like everything being deterministic, but in this case I do not see
>> how it is possible without making the normal case much slower.
>
> I think if you took my (1) suggestion above, it would be deterministic.

Replace "eol=lf" with "eol=crlf" in your script, and you will see that
it does not help with the race.

>
> I absolutely agree, and my first advice upon seeing this jquery repo was
> to fix those line endings. But they went for over a year with the broken
> setup, so clearly it wasn't bothering them. I wonder what git could do
> better to provoke them to fix it sooner.

I believe git should consider all files as "dirty" if .gitattributes is
changed. So, you cannot accidentally commit changes to .gitattributes
without fixing line endings. Currently, you can provoke git to consider
all files as dirty by doing:

  touch -d 2000-1-1 .git/index

but we should not expect users to do that after editing .gitattributes.


Dmitry