On Thu, Aug 10, 2023 at 12:56:31PM -0700, Junio C Hamano wrote:
I have no problem with giving the command an option to allow it to
report if one or more messages were held back via its exit status.
that doesn't give credit to the observation that there is an opportunity
cost to not doing it automatically. it is much easier to imagine that a
scripting user simply didn't consider the possibility of an interactive
cancellation than that they really meant to ignore it. therefore, the
status quo is very likely more harmful than the fallout of starting to
more aggressively report the situation.
Others may even want to know which ones among many messages weren't
sent, not just "there were some that weren't sent", to make it
easier to identify which ones to be resent after touching them up.
yeah, i've considered that as well.
i think that on the exit status side my solution is adequate - it
reports in a sufficiently distinctive way that something didn't go quite
as probably expected.
going further, i'm considering producing a mapping from sha1s to
message-ids (which i'd persist for automatic chaining of re-rolls). this
would provide the fine-grained reporting as a side effect.
regards
