2 messages, 2 authors, 2016-06-15 · open the first message on its own page
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:57
Not quite a related topic, but unless we start to support the copy detection you recommended against, my understanding is that -M does not do anything useful for git-diff-files. Is there a good use case for it? I am not advocating for its removal so please leave the command line option there.
From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:41:57
On Thu, 19 May 2005, Junio C Hamano wrote:
Not quite a related topic, but unless we start to support the copy detection you recommended against, my understanding is that -M does not do anything useful for git-diff-files. Is there a good use case for it? I am not advocating for its removal so please leave the command line option there.
Hmm.. You're right, but it feels kind of wrong. Clearly we support removals in diff-files, but you're right, we can never have something show up as an addition, since we only ever compare against files that are already mentioned in the cache. On the other hand, a unmerged entry really _could_ be a new file, could it not? Even if we right now always report it as "Unmerged path"? If it's a case of existing in stage 2/3 only, it really should show up as a new file diff for git-diff-files, no? Or am I just being confused and/or stupid? Linus