builtin-push: New long option --verbose
PATCH 1/1 builtin-push: New long option --verbose
Implemented and documented new option.
--- Documentation/git-push.txt | 4 ++-- builtin-push.c | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-)
Documentation/git-push.txt +2 -2
@@ -8,7 +8,7 @@ git-push - Update remote refs along with associated objects SYNOPSIS -------- -'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...] +'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...] DESCRIPTION -----------
@@ -91,7 +91,7 @@ the remote repository. transfer spends extra cycles to minimize the number of objects to be sent and meant to be used on slower connection. --v:: +-v, \--verbose:: Run verbosely. include::urls.txt[]
builtin-push.c +3 -2
@@ -8,7 +8,7 @@#define MAX_URI (16) -static const char push_usage[] ="git-push [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]" ; +static const char push_usage[] ="git-push [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]" ;static int all, tags, force, thin =1 , verbose;static const char *receivepack;
@@ -372,7 +372,8 @@ int cmd_push(int argc, const char **argv, const char *prefix) i++;break ; } -if (!strcmp (arg,"-v" )) { +if (!strcmp (arg,"-v" ) || + !strcmp (arg,"--verbose" )) { verbose=1 ;continue ; }
Signature · 1 line
1.5.3.rc5
Why?
Quoted 1 line · Junio C Hamano
Why?
One reason is that I often don't know if the program I want to run (git or something sles) uses -v as the "verbose" flag, or if it's the "version" flag or something else. But if there is a --verbose flag, I can be sure what it is, so I often try that first if I'm unsure. If that faild, I'll probably look in the man page.
Signature · 1 line
David Kågedal
Quoted 1 line · Junio C Hamano
Why?
It complements the command set. -v was the only lonely that did not have long option choice.
Overall, the option handling in every command could use aboot to provide both short and long options. Now various commands have short ones, but no long ones, or vice versa. It's like sherwood there.
Let's start unifying.
Jari
Hi,
Quoted 6 lines · Jari Aalto
Quoted 1 line · Junio C Hamano
Why?
It complements the command set. -v was the only lonely that did not have long option choice.
Of course, the _proper_ solution would be to introduce a complete option parser component a la getopt. For me, it is not _half_ as annoying that some short/long options are missing than being unable to abbreviate the short options into something like "-nls".
Ciao,
Dscho
Hi,
Quoted 1 line · Jari Aalto
Implemented and documented new option.
It is not "new". It is just a long form for the already existing "-v".
Ciao,
Dscho
Quoted 7 lines · Johannes Schindelin
Hi,
Quoted 1 line · Jari Aalto
Implemented and documented new option.
It is not "new". It is just a long form for the already existing "-v".
Perception is in the eye. "new long option"
===========
Jari
Hi,
[please, if you reply to my message, do not kill me from the address list]
Quoted 10 lines · Jari Aalto
Quoted 5 lines · Johannes Schindelin
Quoted 1 line · Jari Aalto
Implemented and documented new option.
It is not "new". It is just a long form for the already existing "-v".
Perception is in the eye. "new long option"
===========
More appropriate: "Add long option --verbose".
Even as a long option, it is not new. There have been plenty "--verbose"s in git before.
It might appear to you as a minor nit, but reading commit logs it is pretty disruptive to read about the "new" option and wondering "why the heck was it not there before? Ah, it was. The committer just added the long version of the option".
Ciao,
Dscho