git/git-send-email.perl, branch v2.40.3

Merge branch 'jc/fix-2.45.1-and-friends-for-2.39' into fixes/2.45.1/2.40

2024-05-24T19:29:36Z

Revert overly aggressive "layered defence" that went into 2.45.1 and friends, which broke "git-lfs", "git-annex", and other use cases, so that we can rebuild necessary counterparts in the open. * jc/fix-2.45.1-and-friends-for-2.39: Revert "fsck: warn about symlink pointing inside a gitdir" Revert "Add a helper function to compare file contents" clone: drop the protections where hooks aren't run tests: verify that `clone -c core.hooksPath=/dev/null` works again Revert "core.hooksPath: add some protection while cloning" init: use the correct path of the templates directory again hook: plug a new memory leak ci: stop installing "gcc-13" for osx-gcc ci: avoid bare "gcc" for osx-gcc job ci: drop mention of BREW_INSTALL_PACKAGES variable send-email: avoid creating more than one Term::ReadLine object send-email: drop FakeTerm hack

send-email: avoid creating more than one Term::ReadLine object

2024-05-21T19:33:07Z

Every time git-send-email calls its ask() function to prompt the user, we call term(), which instantiates a new Term::ReadLine object. But in v1.46 of Term::ReadLine::Gnu (which provides the Term::ReadLine interface on some platforms), its constructor refuses to create a second instance[1]. So on systems with that version of the module, most git-send-email instances will fail (as we usually prompt for both "to" and "in-reply-to" unless the user provided them on the command line). We can fix this by keeping a single instance variable and returning it for each call to term(). In perl 5.10 and up, we could do that with a "state" variable. But since we only require 5.008, we'll do it the old-fashioned way, with a lexical "my" in its own scope. Note that the tests in t9001 detect this problem as-is, since the failure mode is for the program to die. But let's also beef up the "Prompting works" test to check that it correctly handles multiple inputs (if we had chosen to keep our FakeTerm hack in the previous commit, then the failure mode would be incorrectly ignoring prompts after the first). [1] For discussion of why multiple instances are forbidden, see: https://github.com/hirooih/perl-trg/issues/16 [jc: cherry-picked from v2.42.0-rc2~6^2] Signed-off-by: Jeff King Acked-by: Taylor Blau Signed-off-by: Junio C Hamano

send-email: drop FakeTerm hack

2024-05-21T19:33:07Z

Back in 280242d1cc (send-email: do not barf when Term::ReadLine does not like your terminal, 2006-07-02), we added a fallback for when Term::ReadLine's constructor failed: we'd have a FakeTerm object instead, which would then die if anybody actually tried to call readline() on it. Since we instantiated the $term variable at program startup, we needed this workaround to let the program run in modes when we did not prompt the user. But later, in f4dc9432fd (send-email: lazily load modules for a big speedup, 2021-05-28), we started loading Term::ReadLine lazily only when ask() is called. So at that point we know we're trying to prompt the user, and we can just die if ReadLine instantiation fails, rather than making this fake object to lazily delay showing the error. This should be OK even if there is no tty (e.g., we're in a cron job), because Term::ReadLine will return a stub object in that case whose "IN" and "OUT" functions return undef. And since 5906f54e47 (send-email: don't attempt to prompt if tty is closed, 2009-03-31), we check for that case and skip prompting. And we can be sure that FakeTerm was not kicking in for such a situation, because it has actually been broken since that commit! It does not define "IN" or "OUT" methods, so perl would barf with an error. If FakeTerm was in use, we were neither honoring what 5906f54e47 tried to do, nor producing the readable message that 280242d1cc intended. So we're better off just dropping FakeTerm entirely, and letting the error reported by constructing Term::ReadLine through. [jc: cherry-picked from v2.42.0-rc2~6^2~1] Signed-off-by: Jeff King Acked-by: Taylor Blau Signed-off-by: Junio C Hamano

send-email: relay '-v N' to format-patch

2022-11-27T01:21:43Z

send-email relays unrecognized arguments to its format-patch call. Passing '-v N' leads to an error because -v is consumed as send-email's --validate. For example, git send-email -v 3 @{u} fails with fatal: ambiguous argument '3': unknown revision or path not in the working tree. [...] To prevent this, add the short --reroll-count option to send-email's main option list and explicitly provide it to the format-patch call. There other format-patch options that send-email doesn't relay properly, including at least -n, -N, and the diff option -D. Punt on these because dealing with them is more complicated: * they would require configuring send-email to not ignore option case * send-email makes three GetOptions() calls with different sets of options, the last being the main set of options. Unlike -v, which is consumed by the last GetOptions call, the -n, -N, and -D options are consumed as abbreviations by the earlier calls. Signed-off-by: Kyle Meyer Signed-off-by: Junio C Hamano

i18n: fix some badly formatted i18n strings

2022-04-11T21:13:46Z

String in submodule--helper is not correctly formatting placeholders. The string in git-send-email is partial. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

send-email: use 'git hook run' for 'sendemail-validate'

2022-01-07T23:19:35Z

Change the "sendmail-validate" hook to be run via the "git hook run" wrapper instead of via a direct invocation. This is the smallest possibly change to get "send-email" using "git hook run". We still check the hook itself with "-x", and set a "GIT_DIR" variable, both of which are asserted by our tests. We'll need to get rid of this special behavior if we start running N hooks, but for now let's be as close to bug-for-bug compatible as possible. Signed-off-by: Emily Shaffer Signed-off-by: Ævar Arnfjörð Bjarmason Reviewed-by: Emily Shaffer Signed-off-by: Junio C Hamano

send-email docs: add format-patch options

2021-10-28T16:06:15Z

git-send-email(1) does not mention that "git format-patch" options are accepted. Augment SYNOPSIS and DESCRIPTION to mention it. Update git-send-email.perl USAGE to be consistent with git-send-email(1). Signed-off-by: Thiago Perrotta Signed-off-by: Junio C Hamano

send-email: programmatically generate bash completions

2021-10-28T16:04:24Z

"git send-email --git-completion-helper" only prints "format-patch" flags. Make it print "send-email" flags as well, extracting them programmatically from its three existing "GetOptions". Introduce a "uniq" subroutine, otherwise --cc-cover, --to-cover and other flags would show up twice. In addition, deduplicate flags common to both "send-email" and "format-patch", like --from. Remove extraneous flags: --h and --git-completion-helper. Add trailing "=" to options that expect an argument, inline with the format-patch implementation. Add a completion test for "send-email --validate", a send-email flag. Signed-off-by: Thiago Perrotta Based-on-patch-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Merge branch 'ab/send-email-config-fix'

2021-09-15T20:15:24Z

Regression fix. * ab/send-email-config-fix: send-email: fix a "first config key wins" regression in v2.33.0

Merge branch 'mh/send-email-reset-in-reply-to'

2021-09-10T18:46:25Z

Even when running "git send-email" without its own threaded discussion support, a threading related header in one message is carried over to the subsequent message to result in an unwanted threading, which has been corrected. * mh/send-email-reset-in-reply-to: send-email: avoid incorrect header propagation