On Tue, Jul 7, 2009 at 7:54 PM, Junio C Hamano<gitster@xxxxxxxxx> wrote:
> Eric Raible <raible@xxxxxxxxx> 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
--
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