On error, do not list all commands, but point to --help option.
PATCH 1/1 On error, do not list all commands, but point to --help option.
- commented out call to list_common_cmds_help()
- Send error message to stderr, not stdout.
--- help.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
help.c +2 -2
@@ -185,8 +185,8 @@ static void show_man_page(const char *git_cmd)void help_unknown_cmd (const char *cmd) { -printf ("git: '%s' is not a git-command\n\n" , cmd); -list_common_cmds_help (); +fprintf (stderr,"git: '%s' is not a git-command. See --help\n\n" , cmd); +/* list_common_cmds_help(); */ exit (1 ); }
Signature · 3 lines
1.5.3.2.81.g17ed Welcome to FOSS revolution: we fix and modify until it shines
Hi,
Quoted 1 line · Jari Aalto
- commented out call to
list_common_cmds_help()
If you're really sure that this is desired, do not comment it out. Delete it.
But am not at all sure that this is the way to go. Rather, I like it that the most common commands are listed. It would be better to find out what commands are really the most helpful to users who are likely to benefit from the list, and to present them better (such as showing them in categories).
Ciao,
Dscho
* Sat 2007-10-20 Johannes Schindelin <[email protected]> INBOX
Quoted 8 lines
Hi,
Quoted 1 line · Jari Aalto
- commented out call to
list_common_cmds_help()If you're really sure that this is desired, do not comment it out. Delete it.
I'm sure.
There is no point of reminding *every* time you make a typo during writing the commands. It fills half of the screen and obscures the previous commands that were running. It's much more polite and elegant in shorted form.
Jari
New patch follows.
Signature · 1 line
Welcome to FOSS revolution: we fix and modify until it shines
Hi,
Quoted 10 lines · Jari Aalto
* Sat 2007-10-20 Johannes Schindelin <[email protected]> INBOX
Quoted 6 lines · Jari Aalto
Quoted 2 lines
- commented out call to
list_common_cmds_help()If you're really sure that this is desired, do not comment it out. Delete it.
I'm sure.
Well, I'm almost sure of the opposite. One of the big results of the Git Survey was that git is still not user-friendly enough. Your patch would only make this issue worse.
Ciao,
Dscho
Quoted 7 lines · Johannes Schindelin
Quoted 3 lines
Quoted 3 lines · Jari Aalto
Quoted 2 lines
- commented out call to
list_common_cmds_help()Well, I'm almost sure of the opposite. One of the big results of the Git Survey was that git is still not user-friendly enough. Your patch would only make this issue worse.
Actually I think Jari's patch helps for the reason originally stated in the message (less output when you make a small typo). Though I agree that the commented out code should just be removed.
I actually had to do git config alias.upsh push just to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".
Hmm. Lets see.
"cvs foo":
Big spew of commands. Like "git foo".
"svn foo":
Unknown command: 'foo'
Type 'svn help' for usage.
Both are considered to be more newbie friendly then Git. So clearly SVN's output of almost nothing is friendly. And so is CVS' big spew of frequently used commands. Either way is apparently newbie friendly.
Though I find SVN's message a little insulting, asking me to type. I know I have to type the command, thanks.
Signature · 1 line
Shawn.
Quoted 3 lines · Shawn O. Pearce
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".
Yeah, somebody should really work on bash completion...
-Peff
Quoted 7 lines · Jeff King
Quoted 3 lines · Shawn O. Pearce
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".Yeah, somebody should really work on bash completion...
$ git pu<TAB><TAB> pull push
By the time I type out "pus" and hit tab I've already typed out the name "push ". Except I frequently find myself getting the u before the p, which can't complete. Of course with the above alias in place "git u<TAB>" completes out uniquely to "git push " (between bash completion and the alias expansion).
But that alias isn't there for my bash tab completion. Its there exactly because otherwise "git upsh" gives me 31 lines of useless (to me) output without it.
Signature · 1 line
Shawn.
Quoted 18 lines · Shawn O. Pearce
Quoted 7 lines · Jeff King
Quoted 3 lines · Shawn O. Pearce
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".Yeah, somebody should really work on bash completion...
$ git pu<TAB><TAB> pull pushBy the time I type out "pus" and hit tab I've already typed out the name "push ". Except I frequently find myself getting the u before the p, which can't complete. Of course with the above alias in place "git u<TAB>" completes out uniquely to "git push " (between bash completion and the alias expansion).
Quoted 4 lines
But that alias isn't there for my bash tab completion. Its there exactly because otherwise "git upsh" gives me 31 lines of useless (to me) output without it.
My way to resolve this is to define some alias begenning with 'gt' for frequently used commands, such as 'gtps -> git-push, gtpl -> git-pull, gtco->git-checkout, gtci->git-commit, gtbr->git-branch'. so that when i type 'gt<TAB>', only commands that i frequently use are listed.
Signature · 1 line
franky
Quoted 11 lines · Shawn O. Pearce
Quoted 9 lines · Johannes Schindelin
Quoted 3 lines
Quoted 3 lines · Jari Aalto
Quoted 2 lines
- commented out call to
list_common_cmds_help()Well, I'm almost sure of the opposite. One of the big results of the Git
Survey was that git is still not user-friendly enough. Your patch would
only make this issue worse.
Quoted 7 lines
Actually I think Jari's patch helps for the reason originally stated in the message (less output when you make a small typo). Though I agree that the commented out code should just be removed.
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".
If you want to go really user friendly, how about a check against the list of known commands using a shortest-edit distance algorithm?
Unknown command: 'upsh': did you mean 'push'?
Type 'git help' for usage.
Here's just one of many articles introducing the shortest-edit idea, as popularized by Google:
<http://norvig.com/spell-correct.html>
What do you think?
Cheers,
Wincent
Quoted 15 lines · Wincent Colaiuta
Quoted 13 lines · Shawn O. Pearce
Quoted 7 lines · Johannes Schindelin
Quoted 3 lines
Quoted 3 lines · Jari Aalto
Quoted 2 lines
- commented out call to
list_common_cmds_help()Well, I'm almost sure of the opposite. One of the big results of the Git Survey was that git is still not user-friendly enough. Your patch would only make this issue worse.
Actually I think Jari's patch helps for the reason originally stated in the message (less output when you make a small typo). Though I agree that the commented out code should just be removed.
Quoted 6 lines
Quoted 3 lines
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".If you want to go really user friendly, how about a check against the list of known commands using a shortest-edit distance algorithm?
http://en.wikipedia.org/wiki/Levenshtein_distance
Implementing the algorithm doesn't seem terribly difficult.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Quoted 19 lines · Andreas Ericsson
Quoted 18 lines · Wincent Colaiuta
Quoted 17 lines · Shawn O. Pearce
Quoted 8 lines · Johannes Schindelin
Quoted 3 lines
Quoted 3 lines · Jari Aalto
Quoted 2 lines
- commented out call to
list_common_cmds_help()Well, I'm almost sure of the opposite. One of the big results of the Git
Survey was that git is still not user-friendly enough. Your patch would only make this issue worse.Actually I think Jari's patch helps for the reason originally stated in the message (less output when you make a small typo). Though I agree that the commented out code should just be removed.
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".
Quoted 6 lines
Quoted 2 lines
If you want to go really user friendly, how about a check against the list of known commands using a shortest-edit distance algorithm?
http://en.wikipedia.org/wiki/Levenshtein_distance
Implementing the algorithm doesn't seem terribly difficult.
That's not the correct algorithm (you need to consider transpozitions, so you need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but I would not think that's the easier, or faster, way to do it. Though this would have to be benchmarked -- calculating the edit distance is quadratic, while generating the list of possibilities (and seeing whether they exist) is linear, but with large constant. So the question is, whether we have few enough commands that the quadratic calculation might be faster.
Signature · 1 line
Jan 'Bulb' Hudec <[email protected]>
Quoted 22 lines · Jan Hudec
Quoted 13 lines · Andreas Ericsson
Quoted 12 lines · Wincent Colaiuta
Quoted 11 lines · Shawn O. Pearce
Quoted 6 lines · Johannes Schindelin
Quoted 3 lines
Quoted 3 lines · Jari Aalto
Quoted 2 lines
- commented out call to
list_common_cmds_help()Well, I'm almost sure of the opposite. One of the big results of the Git Survey was that git is still not user-friendly enough. Your patch would only make this issue worse.
Actually I think Jari's patch helps for the reason originally stated in the message (less output when you make a small typo). Though I agree that the commented out code should just be removed.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
I actually had to do
git config alias.upsh pushjust to keep myself from screaming every time I made a small typo and Git gave me a screenful of "helpful reminders".If you want to go really user friendly, how about a check against the list of known commands using a shortest-edit distance algorithm?
http://en.wikipedia.org/wiki/Levenshtein_distance
Implementing the algorithm doesn't seem terribly difficult.
Quoted 8 lines
That's not the correct algorithm (you need to consider transpozitions, so you need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but I would not think that's the easier, or faster, way to do it. Though this would have to be benchmarked -- calculating the edit distance is quadratic, while generating the list of possibilities (and seeing whether they exist) is linear, but with large constant. So the question is, whether we have few enough commands that the quadratic calculation might be faster.
It's intended to be used for strings of length 3-14, run through once when the user has given bogus input. We're not gonna index databases here. Simplicity in the implementation almost certainly outweighs the performance penalty of doing it the stupid way.
Signature · 3 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
Quoted 9 lines · Shawn O. Pearce
Hmm. Lets see.
"cvs foo":
Big spew of commands. Like "git foo"."svn foo":
Unknown command: 'foo'
Type 'svn help' for usage.
Quoted 7 lines
Both are considered to be more newbie friendly then Git. So clearly SVN's output of almost nothing is friendly. And so is CVS' big spew of frequently used commands. Either way is apparently newbie friendly.
Though I find SVN's message a little insulting, asking me to type. I know I have to type the command, thanks.
On the contrary, I consider CVS and current Git output more insulting, as it assumes I forgot all the commands every time I made a typo.
The polite part of the message is to point out a typo,
as "Unknown command 'foo'" above. The "Type "svn help" for usage" part is just a reminder for complete newbies, which doesn't take too much space and can be reasonably ignored by experienced users.
PATCH 1/1 On error, do not list all commands, but point to --help option
In reply to Jari Aalto- Remove out call to list_common_cmds_help()
- Send error message to stderr, not stdout.
--- help.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)
help.c +1 -2
@@ -185,8 +185,7 @@ static void show_man_page(const char *git_cmd)void help_unknown_cmd (const char *cmd) { -printf ("git: '%s' is not a git-command\n\n" , cmd); -list_common_cmds_help (); +fprintf (stderr,"git: '%s' is not a git-command. See --help\n\n" , cmd);exit (1 ); }
Signature · 1 line
1.5.3.2.81.g17ed
Re: [PATCH] On error, do not list all commands, but point to --help option
Quoted 1 line · Jari Aalto
- Remove out call to
list_common_cmds_help()
Even if the list is against this change (which I'm in favor of)...
Quoted 1 line
- Send error message to stderr, not stdout.
I really think this really should be done. CVS and SVN both print to stderr in this case, as does any other program I can think of that takes subcommands. Its just the right thing to do.
help.c static void show_man_page(const char *git_cmd) · line 188
Quoted 7 lines
help.c +1
-2@@ -185,8 +185,7 @@ static void show_man_page(const char *git_cmd)void help_unknown_cmd (const char *cmd) { -printf ("git: '%s' is not a git-command\n\n" , cmd); -list_common_cmds_help (); +fprintf (stderr,"git: '%s' is not a git-command. See --help\n\n" , cmd);
Why are you still printing two LFs here? We have no additional text to display after this error message, we probably only need the one LF.
Signature · 1 line
Shawn.
Re: [PATCH] On error, do not list all commands, but point to --help option
Quoted 4 lines · Shawn O. Pearce
Quoted 1 line · Jari Aalto
- Remove out call to
list_common_cmds_help()Even if the list is against this change (which I'm in favor of)...
I didn't get the impression that the _whole_ list is against. I think that the rather longish list should only be shown for 'git help' and when no command was specified (but that is handled by implying help, so this change does not apply to that case), so I am in favor of this.
Signature · 1 line
Jan 'Bulb' Hudec <[email protected]>