Re: [PATCH 1/2] git-send-email.perl: support no- prefix with older GetOptions
On Fri, Feb 13, 2015 at 12:19 PM, Junio C Hamano wrote:
> From: "Kyle J. McKay"
>
> Only Perl version 5.8.0 or later is required, but that comes with
> an older Getopt::Long (2.32) that does not support the 'no-'
> prefix. Support for that was added in Getopt::Long version 2.33.
>
> Since the help only mentions the 'no-' prefix and not the 'no'
> prefix, add explicit support for the 'no-' prefix when running
> with older GetOptions versions.
ultra-ultra-nit: s/when running/for when running/ The current wording
makes it sound like the explicit support is only enabled when running
with older GetOpt versions.
> Reported-by: Tom G. Christensen
> Signed-off-by: Kyle J. McKay
> Signed-off-by: Junio C Hamano
> ---
> git-send-email.perl | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3092ab3..a18a795 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -299,6 +299,7 @@ sub signal_handler {
> "bcc=s" => \@bcclist,
> "no-bcc" => \$no_bcc,
> "chain-reply-to!" => \$chain_reply_to,
> + "no-chain-reply-to" => sub {$chain_reply_to = 0},
> "smtp-server=s" => \$smtp_server,
> "smtp-server-option=s" => \@smtp_server_options,
> "smtp-server-port=s" => \$smtp_server_port,
> @@ -311,25 +312,34 @@ sub signal_handler {
> "smtp-domain:s" => \$smtp_domain,
> "identity=s" => \$identity,
> "annotate!" => \$annotate,
> + "no-annotate" => sub {$annotate = 0},
> "compose" => \$compose,
> "quiet" => \$quiet,
> "cc-cmd=s" => \$cc_cmd,
> "suppress-from!" => \$suppress_from,
> + "no-suppress-from" => sub {$suppress_from = 0},
> "suppress-cc=s" => \@suppress_cc,
> "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
> + "no-signed-off-cc|no-signed-off-by-cc" => sub
> {$signed_off_by_cc = 0},
> "cc-cover|cc-cover!" => \$cover_cc,
I know it's not part of this patch, but does the above duplication of
"cc-cover" do something I'm not aware of? Or should it just be
"cc-cover!"?
> + "no-cc-cover" => sub {$cover_cc = 0},
> "to-cover|to-cover!" => \$cover_to,
Here (above) too.
> + "no-to-cover" => sub {$cover_to = 0},
> "confirm=s" => \$confirm,
> "dry-run" => \$dry_run,
> "envelope-sender=s" => \$envelope_sender,
> "thread!" => \$thread,
> + "no-thread" => sub {$thread = 0},
> "validate!" => \$validate,
> + "no-validate" => sub {$validate = 0},
> "transfer-encoding=s" => \$target_xfer_encoding,
> "format-patch!" => \$format_patch,
> + "no-format-patch" => sub {$format_patch = 0},
> "8bit-encoding=s" => \$auto_8bit_encoding,
> "compose-encoding=s" => \$compose_encoding,
> "force" => \$force,
> "xmailer!" => \$use_xmailer,
> + "no-xmailer" => sub {$use_xmailer = 0},
> );
>
> usage() if $help;
Looks fine to me.
-Brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Getopt::Long workaround in send-email
[apparently it is impossible to send a plain text email using Google Inbox, maybe people on this list know someone to talk to about that? Sorry for the dup for those on cc] On Fri, Feb 13, 2015 at 12:19 PM, Junio C Hamano wrote: > The first one is a replay of Kyle's workaround for older versions of > Getopt::Long that did not take "--no-option" to negate a boolean > option "--option". The second one revert the workarounds made to > the test script over time, and should break if the first one does > not work well for older Getopt::Long (I have no reason to suspect it > would break, though). The only downside I can see is that we're going to end up carrying around these extra options for the forseeable future and possibly adding more over time with this precedent. Maybe that's not so bad. The extra options are not ugly at all. My original thinking in just fixing up the tests was that the platforms with ancient versions of perl/Getopt::Long would just disappear over time and we'd eventually stop fixing up the tests to be backwards compatible when people stopped showing up saying that the tests failed on their ancient system. What platforms are actually affected? RHEL3? Other ancient UNIX? I know the systems I was fixing up were ancient SunOS and IRIX. Unfortunately (or fortunately, depending on how you look at it), I don't have access to any ancient systems to test on anymore. So I can't run the updated tests to make sure they still pass. The patches "look" fine to me though. :-) -Brandon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] t/lib-httpd: switch SANITY check for NOT_ROOT
On 2015-02-12 23.36, Junio C Hamano wrote: > So after discussing this one and queuing the resulting three-patch > series jk/sanity that consists of the three patches: > > * jk/sanity (2015-01-27) 3 commits > - test-lib.sh: set prerequisite SANITY by testing what we really need > - tests: correct misuses of POSIXPERM > - t/lib-httpd: switch SANITY check for NOT_ROOT > > Waiting for ack or counter-proposal from Torsten. > Otherwise looking good. > > Do we want to proceed with these, or do we want any more work done > on them? > I managed to run the tests with POSIXPERM and/or SANITY under Cygwin, Msysgit, Linux, root@linux, Mac and root@Mac. All passed. The work to "be done", what I can see: please amend the commit message: s/more exotic// -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] transport-helper: ask the helper to set the same options for import as for fetch
Mike Hommey writes: > I haven't looked exactly what cas does and if it makes sense for export. > (FWIW, I'm using push and import at the moment, so it's not a direct > issue for me ; I don't support cas anyways) The question primarily came from curiosity to gauge how much potential work remains in the area (of course, people are welcome to share the curiosity and get motivated to fill the gaps as discovered). In other words, I didn't mean to say "complete other methods in transport helper while at it; otherwise your patches are incomplete and unacceptable". It is better to concentrate what you use whose desired behaviour you are sure about, and these two patches do exactly that. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
