Re: [PATCH 0/2] Respecting core.autocrlf when showing objects

From: Marius Storm-Olsen <marius@trolltech.com>
Date: Jun 12, 2008, 09:03 UTC
Message-ID: <4850E647.7050602@trolltech.com>
In-Reply-To: <alpine.DEB.1.00.0806112000400.1783@racer>

Johannes Schindelin said the following on 11.06.2008 21:06:

Show 13 quoted lines

> On Wed, 11 Jun 2008, Marius Storm-Olsen wrote:
>> 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
> 
> This is not really how I would do things.  I would do
> 
> 	git checkout side file.txt here.

Uhm, 'git checkout side file.txt' is not the same file content 
(ignoring EOLs please) as 'git show :3:file.txt'.
Ref: user-manual.html#conflict-resolution

> The _point_ is: "git show" is supposed to show you the contents _in the 
> repository_.  For example, no smudge/clean filters will be heeded, and 
> neither other attributes.

You are describing "git cat-file". IMO, "git show" should have more consideration towards the repo settings. I doubt anyone, excluding yourself and a few more old-timers, think the content they get out from "git show <file>" is *not* the content they'll get when they decide to "git checkout <file>". For most people the commands a mostly the same, except that "show" just stdout-dumps the content, while "checkout" writes it to disk. The subtle difference there is simply just confusing, and is what we need to fix so people won't find Git so hard to use. It's all about usability. Let "git cat-file" do raw dumps, and "git show" what most people would expect.

Seen another way: If you "git show" any object, they are formated in a nice way for the user to see the output; not raw dumps. There's no reason why the user should even consider that when they show a plain blob, *then* it's raw (in the sense that EOLs are not handled properly).

The "show" command is too nice and convenient for it to have such a disrespect for the user.

> Further, "git show" will work without any problems in any bare repository.

Sure, it writes to stdout, and not to file. People understand that.

> In other words: "git show" is _not_ an operation on a working directory.

See above. Nobody expect it to touch files. However, any repo (even bare) still has a config file though, and "git show" should respect its settings.

> "git checkout" is.  So use that instead.

"git checkout" doesn't munge :<stage>:, which is what the documentation is referring to when it comes to conflict resolution.

>> Given that 'git show' *is* porcelain, I'd expect it to work 'naturally' 
>> in my workflow, and not dump raw object store content.
> 
> Do not confuse porcelain with "works on the working directory".

I don't. But I'm trying to see the workflow from a non-git-master POV, you're obviously not.

Show 5 quoted lines

>> 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.
> 
> But it _does_ matter!
> The index works on raw objects, not on smudged files.  Period.

You misunderstood me. I don't smudged files in the index.

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