On Sunday 24 August 2008 05:24:31 Junio C Hamano wrote:
> Alexander Gavrilov <angavrilov@xxxxxxxxx> writes:
>
> > ...
> > git commit -m aaa
> > git config core.autocrlf true
> > git merge b
> >
> > Then look at the output of git diff.
>
> Come to think of it, this test sequence is totally bogus, isn't it?
>
> After making the "aaa" commit, you change core.autocrlf setting, which
> means that at that point your work tree is invalid and needs to be checked
> out with the right crlf.
>
Yes, it is more correct to reset after changing that parameter, but since
merge overwrites the file anyway, I took a shortcut. I first noticed the
problem on Windows, where autocrlf was turned on from the beginning.
By the way, am I right that currently the only way to get properly CRLFed
versions of all stages is to do something like this:
mv -f $path "$path.BACKUP"
git checkout-index -f --stage=1 $path
mv -f $path "$path.BASE"
git checkout-index -f --stage=2 $path
mv -f $path "$path.LOCAL"
git checkout-index -f --stage=3 $path
mv -f $path "$path.REMOTE"
cp -f "$path.BACKUP" $path
git-mergetool does it like this, but it produces LF files:
base_present && git cat-file blob ":1:$prefix$MERGED" >"$BASE" 2>/dev/null
local_present && git cat-file blob ":2:$prefix$MERGED" >"$LOCAL" 2>/dev/null
remote_present && git cat-file blob ":3:$prefix$MERGED" >"$REMOTE" 2>/dev/null
Alexander
--
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
