"Michael S. Tsirkin" [off-list ref] writes:
quoted
quoted
So how did this end up in your mail?
Because it is not a format-patch output.
I often run "git diff --stat -p HEAD" from inside MUA in order
to get the patch from my work tree, write a proposed commit
message, and then reset the change away without committing after
sending that message (yes I do not need "git stash" --- gmane
and vger are my stashes, Mwhhhaaaa).
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)...
Quoting Junio C Hamano [off-list ref]:
Subject: Re: [PATCH] fix parallel make problem
"Michael S. Tsirkin" [off-list ref] writes:
quoted
quoted
quoted
So how did this end up in your mail?
Because it is not a format-patch output.
I often run "git diff --stat -p HEAD" from inside MUA in order
to get the patch from my work tree, write a proposed commit
message, and then reset the change away without committing after
sending that message (yes I do not need "git stash" --- gmane
and vger are my stashes, Mwhhhaaaa).
So maybe we can suppress the warning when the output is not a tty?
What's your point?
Well, git diff currently says "consider running git-status", and one
wanders why doesn't it just go ahead and run git status instead
of asking the user to do it.
--
MST
On Fri, Aug 31, 2007 at 08:44:12AM -0700, Junio C Hamano wrote:
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)...
FWIW, I find the new message terribly ugly compared to the old behavior.
There have been many output changes that I didn't like at first, but for
which I held my tongue and eventually grew to like when they became more
familiar (e.g., the 'subject' line after git-commit).
But I just can't seem to find this one anything but ugly; everytime I
see it, I involuntarily cringe. Perhaps because it really looks like an
error message that accidentally got stuck in the diff output through
incompetent redirection of stdout/stderr.
I say this not to start a flame war (which is perhaps inevitable), but I
just wonder if others feel the same, now that they have had a chance to
get used to it.
-Peff
Hi,
On Fri, 31 Aug 2007, Michael S. Tsirkin wrote:
quoted
Quoting Junio C Hamano [off-list ref]:
Subject: Re: [PATCH] fix parallel make problem
"Michael S. Tsirkin" [off-list ref] writes:
quoted
quoted
quoted
So how did this end up in your mail?
Because it is not a format-patch output.
I often run "git diff --stat -p HEAD" from inside MUA in order
to get the patch from my work tree, write a proposed commit
message, and then reset the change away without committing after
sending that message (yes I do not need "git stash" --- gmane
and vger are my stashes, Mwhhhaaaa).
So maybe we can suppress the warning when the output is not a tty?
What's your point?
Well, git diff currently says "consider running git-status", and one
wanders why doesn't it just go ahead and run git status instead
of asking the user to do it.
I knew why I was opposed to that change. But others shouted louder, I
guess.
Ciao,
Dscho