-generator.shtml
--
View this message in context:
http://git.661346.n2.nabble.com/RFC-PATCH-avoid-SIGPIPE-warnings-for-aliases-tp7574160p7615524.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
On Wed, Jan 09, 2013 at 01:49:41PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But we still say error: ... died of signal 13, because that comes from
inside wait_or_whine. So it is a separate issue whether or not
wait_or_whine should be silent on SIGPIPE (we already are
On Wed, Jan 09, 2013 at 04:18:44PM -0800, Jonathan Nieder wrote:
Do we know if we are upstream of a pager that reads from us through
a pipe (I think we should, especially in a case where we are the one
who processed the git -p $alias option)? Is there any other case
where we would want
On Thu, Jan 10, 2013 at 12:22:49PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Maybe the right rule is if we are using the shell to execute, do not
mention SIGPIPE? It seems a little iffy at first, but:
1. It tends to coincide with direct use of internal tools versus
Am 10.01.2013 21:22, schrieb Junio C Hamano:
Jeff King p...@peff.net writes:
Maybe the right rule is if we are using the shell to execute, do not
mention SIGPIPE? It seems a little iffy at first, but:
1. It tends to coincide with direct use of internal tools versus
external tools.
Johannes Sixt j...@kdbg.org writes:
The interesting cases are when git reads back the output of the command.
Here, a SIGPIPE death of the child would indicate a bug in git, I think,
and some diagnostic would be worth it. But we can just as well declare
that git doesn't have bugs ;)
These
Jeff King p...@peff.net writes:
When git executes an alias that specifies an external
command, it will complain if the alias dies due to a signal.
This is usually a good thing, as signal deaths are
unexpected. However, SIGPIPE is not unexpected for many
commands which produce a lot of
On Wed, Jan 09, 2013 at 12:48:20PM -0800, Junio C Hamano wrote:
$ git lg -p
[user hits 'q' to exit pager]
error: git lgbase --more-options died of signal 13
fatal: While expanding alias 'lg': 'git lgbase --more-options': Success
Many users won't see this, because we execute
Jeff King p...@peff.net writes:
But we still say error: ... died of signal 13, because that comes from
inside wait_or_whine. So it is a separate issue whether or not
wait_or_whine should be silent on SIGPIPE (we already are on SIGINT and
SIGQUIT, as of some recent patches).
The upside is
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But we still say error: ... died of signal 13, because that comes from
inside wait_or_whine. So it is a separate issue whether or not
wait_or_whine should be silent on SIGPIPE (we already are on SIGINT and
SIGQUIT, as of some recent
Jonathan Nieder jrnie...@gmail.com writes:
I'm not sure whether there are SIGPIPE instances we really don't want
to be silent about, though. I suspect not. ;-)
Compare http://thread.gmane.org/gmane.comp.version-control.git/2062,
On Fri, Jan 04, 2013 at 02:20:52PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I have two reservations with this patch:
1. We are ignoring SIGPIPE all the time. For an alias that is calling
log, that is fine. But if pack-objects dies on the server side,
Am 04.01.2013 13:47, schrieb Jeff King:
I have two reservations with this patch:
1. We are ignoring SIGPIPE all the time. For an alias that is calling
log, that is fine. But if pack-objects dies on the server side,
seeing that it died from SIGPIPE is useful data, and we are
On Fri, Jan 04, 2013 at 05:55:18PM +0100, Johannes Sixt wrote:
Am 04.01.2013 13:47, schrieb Jeff King:
I have two reservations with this patch:
1. We are ignoring SIGPIPE all the time. For an alias that is calling
log, that is fine. But if pack-objects dies on the server side,
Jeff King p...@peff.net writes:
I have two reservations with this patch:
1. We are ignoring SIGPIPE all the time. For an alias that is calling
log, that is fine. But if pack-objects dies on the server side,
seeing that it died from SIGPIPE is useful data, and we are
15 matches
Mail list logo
