threads / rfc / 444

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

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

## tl;dr

2 messages between May 2, 2005 and May 3, 2005.

replies: 1people: 2as markdown or json

Junio C Hamano· May 2, 2005, 23:21 UTC · lore
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 ;-).

Linus Torvalds· May 3, 2005, 04:23 UTC · re: Junio C Hamano · lore

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

On Mon, 2 May 2005, Junio C Hamano wrote:
Show 6 quoted lines
> 
>     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:

Show 5 quoted lines
> 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

← back to recent threads