[RFC] git-diff-cache sans --cached and unmerged paths

[RFC] git-diff-cache sans --cached and unmerged paths

[Junio C Hamano]

Linus, 

    git-diff-cache without --cached says 'U filename" (or
"unmerged filename") when working with an unmerged cache entry.
Since the form without --cached is to mean "look at the work
tree", I think it should be changed to report the mode and the
magic 0{40} SHA1.  What do you think?

I was manually fixing up a merge and I wanted to compare the
merge result in the work tree with the pre-merge HEAD version
from either heads, but this behaviour (yes I am the guilty one)
makes it cumbersome, and that is the reason behind this
question.

BTW, when you have a chance, could you please give the
executable bit to git-apply-patch-script, pretty please.  This
is my fourth attempt ;-).

Re: [RFC] git-diff-cache sans --cached and unmerged paths

[Linus Torvalds]

On Mon, 2 May 2005, Junio C Hamano wrote:
> 
>     git-diff-cache without --cached says 'U filename" (or "unmerged
> filename") when working with an unmerged cache entry. Since the form
> without --cached is to mean "look at the work tree", I think it should
> be changed to report the mode and the magic 0{40} SHA1.  What do you
> think?

Hmm.. I like the "it's unmerged, so we report it that way" thing, but on 
the other hand, what you describe as your workflow:

> I was manually fixing up a merge and I wanted to compare the
> merge result in the work tree with the pre-merge HEAD version
> from either heads, but this behaviour (yes I am the guilty one)
> makes it cumbersome, and that is the reason behind this
> question.

This seems to make sense as a workflow perspective, so I guess I'll have 
to agree. A unmerged file that exists in the working tree should probably 
get reported as the working tree version, not as unmerged.

If it's not in the working tree at all, I'd assume that "U" is the right 
thing to do (and obviously, with "--cached" there is no question about 
it).

> BTW, when you have a chance, could you please give the
> executable bit to git-apply-patch-script, pretty please.  This
> is my fourth attempt ;-).

I just sent you a description of the problem I had with your tree, so 
maybe fifth time lucky..

		Linus