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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano said the following on 11.06.2008 00:25:
Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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'

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux