Removed the printf("rm 'file'") from git-rm.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Tilman Sauerbeck
We used to print that, because you actually had to run the output of git-rm to get rid of the files before Git 1.5. Now that git-rm really removes the files, it's not needed anymore.
Even though I admit I do not deeply care, as I never use 'git rm' myself, I do not necessarily agree with "because" part.
I suspect people are by now accustomed to see the assuring feedback from the command when used this way:
$ git rm -r one
rm 'one/1'
rm 'one/2'
rm 'one/3'and even in non-recursive case, expect the similar output for consistecy's sake.
Junio C Hamano [2007-03-24 23:22]:
Quoted 6 lines
Quoted 3 lines · Tilman Sauerbeck
We used to print that, because you actually had to run the output of git-rm to get rid of the files before Git 1.5. Now that git-rm really removes the files, it's not needed anymore.
Quoted 6 lines
Even though I admit I do not deeply care, as I never use 'git rm' myself, I do not necessarily agree with "because" part.
I suspect people are by now accustomed to see the assuring feedback from the command when used this way:
[snip]
Too bad, I find it rather annoying and irritating.
Regards,
Tilman
Signature · 4 lines
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hi,
Quoted 7 lines · Tilman Sauerbeck
Junio C Hamano [2007-03-24 23:22]:
Quoted 6 lines
Quoted 3 lines · Tilman Sauerbeck
We used to print that, because you actually had to run the output of git-rm to get rid of the files before Git 1.5. Now that git-rm really removes the files, it's not needed anymore.
Quoted 8 lines
Quoted 6 lines
Even though I admit I do not deeply care, as I never use 'git rm' myself, I do not necessarily agree with "because" part.
I suspect people are by now accustomed to see the assuring feedback from the command when used this way:
[snip]Too bad, I find it rather annoying and irritating.
Why not do the common thing, and add a "--quiet" option? You can even add a config variable to enable it by default (for git-rm). It's not like git-rm is performance critical...
Quoted 4 lines
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Funny!
Ciao,
Dscho
PATCH 1/1 git-rm: add --quiet option to suppress "rm 'file'" messages
---
Quoted 6 lines · Johannes Schindelin
Quoted 1 line
Too bad, I find it rather annoying and irritating.
Why not do the common thing, and add a "--quiet" option? You can even add a config variable to enable it by default (for git-rm). It's not like git-rm is performance critical...
Is something like this right?
builtin-rm.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
builtin-rm.c +5 -2
@@ -114,7 +114,7 @@ static struct lock_file lock_file;int cmd_rm (int argc,const char **argv,const char *prefix) {int i, newfd; -int show_only =0 , force =0 , index_only =0 , recursive =0 ; +int show_only =0 , force =0 , index_only =0 , recursive =0 , quiet =0 ;const char **pathspec;char *seen;
@@ -142,6 +142,8 @@ int cmd_rm(int argc, const char **argv, const char *prefix) force =1 ; else if (!strcmp(arg, "-r")) recursive =1 ; + else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) + quiet =1 ; elseusage (builtin_rm_usage ); }
@@ -197,7 +199,8 @@ int cmd_rm(int argc, const char **argv, const char *prefix)*/ for (i =0 ; i < list.nr; i++) {const char *path = list.name[i]; -printf ("rm '%s'\n" , path); +if (!quiet) +printf ("rm '%s'\n" , path);if (remove_file_from_cache (path))die ("git-rm: unable to remove %s" , path);
Signature · 1 line
1.5.1-rc1.GIT
Re: [PATCH] git-rm: add --quiet option to suppress "rm 'file'" messages
Quoted 30 lines · Eric Lesh
Signed-off-by Eric Lesh <[email protected]>---
Quoted 5 lines · Johannes Schindelin
Quoted 1 line
Too bad, I find it rather annoying and irritating.
Why not do the common thing, and add a "--quiet" option? You can even add a config variable to enable it by default (for git-rm). It's not like git-rm is performance critical...
Is something like this right?
builtin-rm.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)builtin-rm.c +1
-1@@ -114,7 +114,7 @@ static struct lock_file lock_file;int cmd_rm (int argc,const char **argv,const char *prefix) {int i, newfd; -int show_only =0 , force =0 , index_only =0 , recursive =0 ; +int show_only =0 , force =0 , index_only =0 , recursive =0 , quiet =0 ;const char **pathspec;char *seen;
builtin-rm.c int cmd_rm(int argc, const char **argv, const char *prefix) · line 206
Quoted 9 lines
builtin-rm.c +2
-1@@ -197,7 +199,8 @@ int cmd_rm(int argc, const char **argv, const char *prefix)*/ for (i =0 ; i < list.nr; i++) {const char *path = list.name[i]; -printf ("rm '%s'\n" , path); +if (!quiet) +printf ("rm '%s'\n" , path);if (remove_file_from_cache (path))die ("git-rm: unable to remove %s" , path);
I wonder how this would interact with show_only...
hoi :)
Quoted 3 lines · Johannes Schindelin
Why not do the common thing, and add a "--quiet" option? You can even add a config variable to enable it by default (for git-rm). It's not like git-rm is performance critical...
But when we have to add --quiet to all sorts of commands that may be the sign that they really are too chatty.
If I want a short output I don't want to type extra options. So adding a --verbose for those that really depend on more output makes more sense, IMHO. (Even when I don't see any useful information in the git-rm output, to be honest.)
Signature · 1 line
Martin Waitz
Quoted 9 lines · Junio C Hamano
Quoted 3 lines · Tilman Sauerbeck
We used to print that, because you actually had to run the output of git-rm to get rid of the files before Git 1.5. Now that git-rm really removes the files, it's not needed anymore.
Even though I admit I do not deeply care, as I never use 'git rm' myself, I do not necessarily agree with "because" part.
Quoted 7 lines
I suspect people are by now accustomed to see the assuring feedback from the command when used this way:
$ git rm -r one rm 'one/1' rm 'one/2' rm 'one/3'
Heh. I didn't even know there was a recursive option. So I'm definitely not 'accustomed' to any form of output.
If me being a data point helps at all.
Anand