Junio C Hamano said the following on 11.06.2008 00:25:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Tue, 10 Jun 2008, Marius Storm-Olsen wrote:
>>> When you use 'git show <rev>:<file>' or 'git show :<stage>:<file>', the 
>>> objects are shows as they are in the object store, ignoring the 
>>> core.autocrlf configuration.
>> I think this is the correct behaviour: inside the object repository, the 
>> files are supposed to be LF clean.
>>
>> Likewise, things in the unmerged stages are in the index, which again is 
>> not the working directory, so they should be LF clean.
>>
>> _Only_ when writing a file to the working directory, it should get 
>> clobbered.
> 
> I'd agree with your argument on general principle, but it might make sense
> to give an option to let you say "here is a blob contents, and use the
> attribute for this path to munge it out to the filesystem."  I am not sure
> if that belongs to "git show" Porcelain, though.  It _could_ be more like:
> 
>         git checkout-blob $blob_sha1 $path
> 
> that (1) reads the blob object specified by its object name, (2)
> grabs attribute for the $path, and (3) applies convert_to_worktree()
> filtering given that attribute and deposits the results to $path.
> 
> Alternatively, the interface could be:
> 
>         git cat-file blob $blob_sha1 |
>         git filter-blob --use-attr-for=$path >$path.old
> 
> so that you can then do:
> 
> 	git diff --no-index $path.old $path
> 
> I dunno.

Well, consider this:
Say you are merging two branches, and know that you want to just use 
the parts which conflict from the branch being merged in. Then you 
simply do:
	git merge side
	git show :3:file.txt > file.txt
	git add file.txt
	git commit ...blah blah...

Now, with the current behavior, this workflow breaks for 
core.autocrlf=true repos. Given that 'git show' *is* porcelain, I'd 
expect it to work 'naturally' in my workflow, and not dump raw object 
store content.
However, I also see that it can be useful at times. Almost makes me 
consider a --raw option to 'git show' for those seldom cases. IMO, 
'git show' *should* care about autocrlf. Not doing so is just 
confusing to the end-user.

The fact that the stage files are in the index doesn't matter. I'd 
want CRLF files from 'git show v1.5.6-rc0:builtin-log.c' as well.

-- 
.marius [@trolltech.com]
'if you know what you're doing, it's not research'