On Mon, 28 May 2007, Jim Meyering wrote:
>
> I suspect that git's special treatment of EPIPE was a shoot-the-messenger
> reaction to the work-around (trap '' PIPE) required to avoid diagnostics
> from porcelain being interpreted by what would now be a 2-year-old
> version of bash.
No. You don't seem to realize. That was the *default* behaviour of bash.
For all I know, it might _still_ be the default behaviour.
The only reason not everybody ever even noticed, was that most
distributions were clueful enough to have figured out that it was broken,
and configured bash separately. But "most" does not mean "all", and I had
this problem on powerpc, and others had it on Debian, I htink (might have
been slackware). I think RH and SuSE had both fixed it explicitly.
> diff --git a/write_or_die.c b/write_or_die.c
> index 5c4bc85..fadfcaa 100644
> --- a/write_or_die.c
> +++ b/write_or_die.c
> @@ -41,8 +41,6 @@ int write_in_full(int fd, const void *buf, size_t count)
> void write_or_die(int fd, const void *buf, size_t count)
> {
> if (write_in_full(fd, buf, count) < 0) {
> - if (errno == EPIPE)
> - exit(0);
> die("write error (%s)", strerror(errno));
Nack. Nack. NACK.
I think this patch is fundamentally WRONG. This fragment is just a prime
example of why the whole patch is crap. The old code was correct, and you
broke it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
