Re: [PATCH] fix parallel make problem

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> ...
>> So maybe we can suppress the warning when the output is not a tty?
>
> What's your point?
>
> I did not even want to apply that "empty diff --git removal"
> patch.  I certainly do _NOT_ want to suppress that replacement
> warning anywhere.
>
> You are seriously tempting me to revert the commit
> fb13227e089f22dc31a3b1624559153821056848 (git-diff: squelch
> "empty" diffs)...

This probably needs clarification.

That warning came because I was experimenting your reproduction
recipe of touching revision.c before building.  In earlier git,
it would have shown "diff --git a/revision.c b/revision.c"
without any actual diff text to remind me of that fact, and I
would have liked it better than the current "warning at the end"
behaviour for this particular case.  It was a reminder that my
recollection of what I did (and what my understanding of what
the state of my work tree is) matches the reality, but the new
"squelched" behaviour lost that value.

With the older git, whenever I sent out such a "this is how you
would do it" patch without committing [*1*], I removed those
"expected to be empty" diffs by hand after making a mental note
that these were to be expected and my understanding of where I
am matches reality.  It was a good thing.

The new "single warning at the end" was deliberately done to
reduce the "clutter" (which, this exchange is reminding me was
not clutter at all but valuable information) as a response to
requests from some people on the list, but because it was made
much less visible, it made me to miss it.

Having said that, I am _not_ going to revert that change at this
late in the game, but I am really tempted to add an option and a
configuration variable to revive the original behaviour (and of
course I'd set that configuration variable in _my_ repository).


[Footnote]

*1* Most of the patches I send out to the list are done that
way; I do "commit then send patch" much less often than "edit,
test, send 'diff HEAD' to the list and reset, intending to later
"am" it from the list if it is accepted favourably on the list".