{"thread":{"id":"444","subject":"[RFC] git-diff-cache sans --cached and unmerged paths","startedAt":"2005-05-02T23:21:33Z","lastAt":"2005-05-03T04:23:05Z","messageCount":2,"participants":["Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2414","messageId":"7vr7gpnria.fsf@assigned-by-dhcp.cox.net","threadId":"444","inReplyTo":null,"subject":"[RFC] git-diff-cache sans --cached and unmerged paths","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-02T23:21:33Z","receivedAt":"2005-05-02T23:21:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus, \n\n    git-diff-cache without --cached says 'U filename\" (or\n\"unmerged filename\") when working with an unmerged cache entry.\nSince the form without --cached is to mean \"look at the work\ntree\", I think it should be changed to report the mode and the\nmagic 0{40} SHA1.  What do you think?\n\nI was manually fixing up a merge and I wanted to compare the\nmerge result in the work tree with the pre-merge HEAD version\nfrom either heads, but this behaviour (yes I am the guilty one)\nmakes it cumbersome, and that is the reason behind this\nquestion.\n\nBTW, when you have a chance, could you please give the\nexecutable bit to git-apply-patch-script, pretty please.  This\nis my fourth attempt ;-).\n\n\n"},{"id":"2445","messageId":"Pine.LNX.4.58.0505022119540.3594@ppc970.osdl.org","threadId":"444","inReplyTo":"7vr7gpnria.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git-diff-cache sans --cached and unmerged paths","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-03T04:23:05Z","receivedAt":"2005-05-03T04:23:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 2 May 2005, Junio C Hamano wrote:\n> \n>     git-diff-cache without --cached says 'U filename\" (or \"unmerged\n> filename\") when working with an unmerged cache entry. Since the form\n> without --cached is to mean \"look at the work tree\", I think it should\n> be changed to report the mode and the magic 0{40} SHA1.  What do you\n> think?\n\nHmm.. I like the \"it's unmerged, so we report it that way\" thing, but on \nthe other hand, what you describe as your workflow:\n\n> I was manually fixing up a merge and I wanted to compare the\n> merge result in the work tree with the pre-merge HEAD version\n> from either heads, but this behaviour (yes I am the guilty one)\n> makes it cumbersome, and that is the reason behind this\n> question.\n\nThis seems to make sense as a workflow perspective, so I guess I'll have \nto agree. A unmerged file that exists in the working tree should probably \nget reported as the working tree version, not as unmerged.\n\nIf it's not in the working tree at all, I'd assume that \"U\" is the right \nthing to do (and obviously, with \"--cached\" there is no question about \nit).\n\n> BTW, when you have a chance, could you please give the\n> executable bit to git-apply-patch-script, pretty please.  This\n> is my fourth attempt ;-).\n\nI just sent you a description of the problem I had with your tree, so \nmaybe fifth time lucky..\n\n\t\tLinus\n"}]}