git-clone --quiet broken?

git-clone --quiet broken?

[Dave Jones]

The server I run various git snapshots on recently got upgraded to git 1.5.6,
and I started getting a lot more mail from cron than usual.
It seems that passing -q to git-clone at some point changed from 'silent'
to 'slightly less noisy'. Only the difference is so slight that it may
as well be nil..

Here's a normal clone..

Initialize git/.git
Initialized empty Git repository in /home/davej/git-trees/git/.git/
remote: Counting objects: 76925, done.
remote: Compressing objects: 100% (25373/25373), done.
remote: Total 76925 (delta 55699), reused 70336 (delta 50160)
Receiving objects: 100% (76925/76925), 17.09 MiB | 1111 KiB/s, done.
Resolving deltas: 100% (55699/55699), done.

And here's the 'quiet' clone..

Initialize git/.git
remote: Counting objects: 76925, done.
remote: Compressing objects: 100% (25373/25373), done.
remote: Total 76925 (delta 55699), reused 70336 (delta 50160)
Receiving objects: 100% (76925/76925), 17.09 MiB | 1128 KiB/s, done.
Resolving deltas: 100% (55699/55699), done.

Spot the difference :)

It looks even worse in mail from cron, where you get one line of text
for every % that git progresses through.

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?

	Dave

-- 
http://www.codemonkey.org.uk

Re: git-clone --quiet broken?

[Junio C Hamano]

Dave Jones <davej@codemonkey.org.uk> 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++)

Re: git-clone --quiet broken?

[Daniel Barkalow]

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

> Dave Jones <davej@codemonkey.org.uk> 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.

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 <barkalow@iabervon.org>

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

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

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

Re: git-clone --quiet broken?

[Alex Riesen]

Junio C Hamano, Sun, Jul 06, 2008 02:56:17 +0200:
> Dave Jones <davej@codemonkey.org.uk> 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.

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);
 
 	/*

Re: git-clone --quiet broken?

[Daniel Barkalow]

On Mon, 7 Jul 2008, Alex Riesen wrote:

> 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);
>  
>  	/*

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

Acked-by: Daniel Barkalow <barkalow@iabervon.org>