From: Eric Raible <raible@gmail.com>
Date: Wed, 08 Jul 2009 06:13:01 GMT
Subject: Re: Schrödinger's diff
Message-ID: <279b37b20907072313t79ddded2k84c819887c234e8b@mail.gmail.com>
In-Reply-To: <7v8wizanqr.fsf@alter.siamese.dyndns.org>

On Tue, Jul 7, 2009 at 7:54 PM, Junio C Hamano<gitster@pobox.com> wrote:
> Eric Raible <raible@gmail.com> writes:
>
>> So what's the best way of "fixing once and for all" a repo infected with
>> carriage returns when you want to use autocrlf=true moving forward?
>
> Didn't "rm -f .git/index && git reset --hard HEAD" work?

Will, it "worked" in the sense that it usually [1] allows
"git diff --name-only" to correctly show the files that were
checked in with crlf endings and core.autocrlf false.

Those files are then out-of-date when core.autocrlf is
true and .git/index is up-to-date.

In other words, that first step worked around the fact
that sometimes that .git/index was out of date.

By "fixing it once and for all" I was trying to refer to creating
the correct commit to abolish the carriage returns from my repo.

I ended up with this crude-but-obvious loop which
generates many LF->CRLF warnings [2]:

for i in `git diff --name-only`; do
      echo $i
      sed 's/0x0D//' < $i > foo
      mv foo $i
      git add $i
done

>> Would you accept a patch explaining how "git reset --hard" doesn't
>> actually rebuild the index from scratch,...
>
> Absolutely.

I'll try to get to it, given the $dayjob / $significant_other constraints.

- Eric

[1] I've had cases where for whatever reasons a "git read-tree HEAD"
     seemed to be required, but I don't have the recipe yet.
[2] Which can be abolished by wrapping it in autocrlf=false
     before and autocrlf=true after