Re: [PATCH] Removed the printf("rm 'file'") from git-rm.

Tilman Sauerbeck [off-list ref] writes:

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.

On Sat, 24 Mar 2007 23:22:16 -0700, Junio C Hamano wrote:

Tilman Sauerbeck [off-list ref] writes:

quoted

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'

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

Junio C Hamano [2007-03-24 23:22]:

Tilman Sauerbeck [off-list ref] writes:

quoted

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:
[snip]

Too bad, I find it rather annoying and irritating.

Regards,
Tilman

-- 
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,

On Sun, 25 Mar 2007, Tilman Sauerbeck wrote:

Junio C Hamano [2007-03-24 23:22]:

quoted

Tilman Sauerbeck [off-list ref] writes:

quoted

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:
[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...

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

Signed-off-by: Eric Lesh <redacted>

---

On Sun, 2007-03-25 at 23:36 +0200, Johannes Schindelin wrote:

quoted

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(-)

diff --git a/builtin-rm.c b/builtin-rm.c
index 00dbe39..d193fb0 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c

@@ -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;
 		else
 			usage(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);

-- 
1.5.1-rc1.GIT

hoi :)

On Sun, Mar 25, 2007 at 11:36:35PM +0200, Johannes Schindelin wrote:

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.)

-- 
Martin Waitz

Eric Lesh [off-list ref] writes:

I wonder how this would interact with show_only...