Jeff King <peff@xxxxxxxx> writes: > On Wed, Jan 18, 2017 at 12:57:12PM -0800, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > So I dunno. A sensible rule to me is "iff -p would show a diff header, >> > then --stat should mention it". >> >> True but tricky (you need a better definition of "a diff header"). >> >> In addition to a new and deleted file, does a file whose executable >> bit was flipped need mention? If so, then "diff --git" is the diff >> header in the above. Otherwise "@@ ... @@", iow, "iff -p would show >> any hunk". >> >> I think the patch implements the latter, which I think is sensible. > > I would think the former is more sensible (and is what my patch is > working towards). Doh (yes, "diff --git" was what I meant). As a mode-flipping patch does not have hunk but does show the header, it wants to be included in "git diff --stat" output, I would think, independent of -b issue. In fact chmod +x README.md git diff --stat does show a 0-line diffstat. > Doing: > > >empty > git add empty > git diff --cached > > shows a "diff --git" header, but no hunk. I think it should show a > diffstat (and does with my patch). > > I was thinking the rule should be something like: > > if (p->status == DIFF_STATUS_MODIFIED && > !file->added && !file->deleted)) > > and otherwise include the entry, since it would be an add, delete, > rename, etc, which carries useful information. > > Though a pure rename would not hit this code path at all, I would think > (it would not trigger "!same_contents"). And a rename where there was a > whitespace only change probably _should_ be omitted from "-b". > > Ditto for a pure mode change, I think. We do not run the contents > through diff at all, so it does not hit this code path. > > -Peff