# [RFC] git-diff-cache sans --cached and unmerged paths 2 messages from 2005-05-02 to 2005-05-03. Participants: Junio C Hamano, Linus Torvalds. Thread: https://gitlist.dev/t/444 ## Junio C Hamano, 2005-05-02 23:21 Subject: [RFC] git-diff-cache sans --cached and unmerged paths Message-ID: <7vr7gpnria.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7gpnria.fsf%40assigned-by-dhcp.cox.net ``` 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, 2005-05-03 04:23 Subject: Re: [RFC] git-diff-cache sans --cached and unmerged paths Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0505022119540.3594%40ppc970.osdl.org In-Reply-To: <7vr7gpnria.fsf@assigned-by-dhcp.cox.net> ``` 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 ```