Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Is the motivation purely a UX change where it's considered that the user > *must* be shown the output, or are we doing the wrong thing and not > continuing at all if we run into SIGPIPE here (then presumably only for > hooks that produce output?). > > I admit this is somewhat contrived, but aren't we now doing worse for > users where the pre-receive hook takes 10s, but they already asked for > their push to be performed. Then they disconnect from WiFi unexpectedly, > and find that that it didn't go through? > > Anyway, I see you made this opt-in configurable in earlier iterations. I > wonder if that's still something worth doing, or if we should just take > this change as-is. I guess the above is exactly the same reaction I still have against the series. In a case where the user did *not* see "git push" complete after getting a positive response from the other side that says the changes to refs have succeeded, due to whatever reason (e.g. "^C" or connection droppage), the user cannot expect whether the push to have completed or got aborted, both from the UX point of view and from the correctness point of view, I would think. Your keyboard interrupt "^C" may have come too late to matter at the receiving end, or your WiFi may or may not have disconnected before the receiving end got everything necessary from you to carry out the operation, for example, and you are not simply in control of these things.
