From: Alexander Gavrilov <angavrilov@gmail.com>
Date: Sun, 24 Aug 2008 09:21:57 GMT
Subject: Re: [PATCH (BUGFIX)] Respect core.autocrlf in combined diff
Message-ID: <200808241321.58791.angavrilov@gmail.com>
In-Reply-To: <7vy72nurw0.fsf@gitster.siamese.dyndns.org>

On Sunday 24 August 2008 05:24:31 Junio C Hamano wrote:
> Alexander Gavrilov <angavrilov@gmail.com> 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