Re: git-clone --quiet broken?

Dave Jones [off-list ref] writes:

The server I run various git snapshots on recently got upgraded to git 1.5.6,
...
I could run the clone with 2>/dev/null, but I'd really like to get
mail when something breaks instead of it being totally silent.

I'm assuming this was an unintentional side-effect of some other recent change?

Yeah, I would assume so, too ;-)

Daniel, is this enough?  From re-reading the scripted version of
git-clone, it appears that we *might* need to squelch no-progress if the
stdout is not tty;  I do not offhand if you got that right when you
rewrote this in C.

 transport.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/transport.c b/transport.c
index 3ff8519..b2f0d8a 100644
--- a/transport.c
+++ b/transport.c

@@ -645,7 +645,8 @@ static int fetch_refs_via_pack(struct transport *transport,
 	args.lock_pack = 1;
 	args.use_thin_pack = data->thin;
 	args.include_tag = data->followtags;
-	args.verbose = transport->verbose > 0;
+	args.verbose = (transport->verbose > 0);
+	args.quiet = (transport->verbose < 0);
 	args.depth = data->depth;
 
 	for (i = 0; i < nr_heads; i++)

On Sat, 5 Jul 2008, Junio C Hamano wrote:

Dave Jones [off-list ref] writes:

quoted

The server I run various git snapshots on recently got upgraded to git 1.5.6,
...
I could run the clone with 2>/dev/null, but I'd really like to get
mail when something breaks instead of it being totally silent.

I'm assuming this was an unintentional side-effect of some other recent change?

Yeah, I would assume so, too ;-)

Daniel, is this enough?  From re-reading the scripted version of
git-clone, it appears that we *might* need to squelch no-progress if the
stdout is not tty;  I do not offhand if you got that right when you
rewrote this in C.

This is probably enough for what people actually care about (when stdout 
isn't a tty and isn't /dev/null, people are likely to ask for "quiet" 
anyway, because this command's output isn't interesting after the fact). 
But no-progress is probably a good idea anyway.

Oh, and you're fixing the corresponding regressions in fetch, which nobody 
seems to have mentioned previously.

Acked-by: Daniel Barkalow <redacted>

And:
+	args.no_progress = !isatty(1);

 	args.depth = data->depth;
 
 	for (i = 0; i < nr_heads; i++)

Junio C Hamano, Sun, Jul 06, 2008 02:56:17 +0200:

Dave Jones [off-list ref] writes:

quoted

The server I run various git snapshots on recently got upgraded to git 1.5.6,
...
I could run the clone with 2>/dev/null, but I'd really like to get
mail when something breaks instead of it being totally silent.

I'm assuming this was an unintentional side-effect of some other recent change?

Yeah, I would assume so, too ;-)

Daniel, is this enough?  From re-reading the scripted version of
git-clone, it appears that we *might* need to squelch no-progress if the
stdout is not tty;  I do not offhand if you got that right when you
rewrote this in C.

While at it, could we please have the first "Initialize" message
removed?

    Initialize git/.git
    Initialized empty Git repository in /home/davej/git-trees/git/.git/

The default output looks redundant (that of init_db too, but the full
path can be useful sometimes). Something like this, perhaps:

diff --git a/builtin-clone.c b/builtin-clone.c
index 643c7d4..4a0f1ab 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c

@@ -421,7 +421,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		die("could not create leading directories of '%s'", git_dir);
 	set_git_dir(make_absolute_path(git_dir));
 
-	fprintf(stderr, "Initialize %s\n", git_dir);
 	init_db(option_template, option_quiet ? INIT_DB_QUIET : 0);
 
 	/*

On Mon, 7 Jul 2008, Alex Riesen wrote:

Yeah, that's clearly left-over debugging, and I think that's the only one 
left from this conversion, anyway.

Acked-by: Daniel Barkalow <redacted>