Re: [PATCH] fix parallel make problem

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 31, 2007, 16:01 UTC
Message-ID: <7vmyw71yn5.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vr6lj1zg3.fsf@gitster.siamese.dyndns.org>

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

Show 13 quoted lines

> "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".