Oswald Buddenhagen <oswald.buddenhagen@xxxxxx> writes:
> Proposed content for RelNotes:
>
> * "git send-email" now reports interactive cancellation via a distinct
> non-zero exit status. Callers which do not consider this situation an
> error need to be adjusted.
If we still want to deliberately break folks with this change, we
should not blame users for becoming accustomed to the traditional
behaviour and pretend as if burdening them to change their scripts
is within our rights. We should be a lot more apologetic in the
backward compatibility notes than what you wrote in the above.
Having said that, quite honestly, I do not think this new behaviour
deserves to be a new default from the day one, with need for an
apology to existing users by the project. Given that the users have
lived with the current behaviour practically forever in Git's
timescale and that not changing the default and letting them "live
with" the status quo cannot cause any serious problem, I cannot
stand behind such a default change myself. It should be a new
feature that is opt-in, just like any other new and useful feature..
By the way, I just noticed that the test will not pass on BSD
derived systems. Something like this need to be squashed in if we
want to proceed further.
--- >8 --- squash --- >8 ---
Subject: [PATCH] SQUASH???
Sending "wc -l" output to a file and expecting that it has a run of
digits with terminating newline and nothing else is prone to break
on BSD derived systems, including macOS.
---
t/t9001-send-email.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 64f9c7c154..8323783963 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1198,7 +1198,7 @@ test_confirm_many () {
-2 <replies
echo $? >exit_sts
test_cmp expected_sts exit_sts || return 1
- ls commandline* 2>/dev/null | wc -l >num_mails
+ echo $(ls commandline* 2>/dev/null | wc -l) >num_mails
test_cmp expected_num num_mails || return 1
}
--
2.42.0-81-g1a190bc14a
