Eric Raible [off-list ref] 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?
And a hopefully less annoying one:
Would you accept a patch explaining how "git reset --hard" doesn't
actually rebuild the index from scratch,...
Absolutely.
... and how "git read-head" might
be recommended in some weird situations?
I am less certain about that; people may have easier-to-read solution than
the one with read-tree, I would suspect.
On Tue, Jul 7, 2009 at 7:54 PM, Junio C Hamano[off-list ref] wrote:
Eric Raible [off-list ref] writes:
quoted
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
quoted
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