git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: bill lam <cbill.lam@gmail.com>
Cc: Nicolas Pitre <nico@fluxnic.net>, git <git@vger.kernel.org>
Subject: Re: how to suppress progress percentage in git-push
Date: Mon, 23 Nov 2009 10:00:00 -0500	[thread overview]
Message-ID: <20091123145959.GA13138@sigill.intra.peff.net> (raw)
In-Reply-To: <20091122145352.GA3941@debian.b2j>

On Sun, Nov 22, 2009 at 10:53:53PM +0800, bill lam wrote:

> I set crontab to push to another computer for backup. It sent
> confirmation email after finished.  It looked like
> 
> Counting objects: 1
> Counting objects: 9, done.
> Delta compression using up to 2 threads.
> Compressing objects:  20% (1/5)
> Compressing objects:  40% (2/5)
> Compressing objects:  60% (3/5)
> Compressing objects:  80% (4/5)
> Compressing objects: 100% (5/5)
> Compressing objects: 100% (5/5), done.
> Writing objects:  20% (1/5)
> Writing objects:  40% (2/5)
> Writing objects:  60% (3/5)
> Writing objects:  80% (4/5)
> Writing objects: 100% (5/5)
> Writing objects: 100% (5/5), 549 bytes, done.
> Total 5 (delta 3), reused 0 (delta 0)
> 
> Often the list of progress % can be a page long.  I want output but
> not those percentage progress status.  Will that be possible?

Hmm. There seems to be a bug. pack-objects is supposed to see that
stderr is not a tty and suppress the progress messages. But it doesn't,
because send-pack gives it the --all-progress flag, which
unconditionally tells it to display progress, when the desired impact is
actually to just make the progress more verbose.

We need to do one of:

  1. make --all-progress imply "if we are using progress, then make it
     more verbose. Otherwise, ignore."

  2. fix all callers to check isatty(2) before unconditionally passing
     the option

The patch for (1) would look something like what's below.  It's simpler,
but it does change the semantics; anyone who was relying on
--all-progress to turn on progress unconditionally would need to now
also use --progress. However, turning on progress unconditionally is
usually an error (the except is if you are piping output in real-time to
the user and need to overcome the isatty check).

Nicolas, this is your code. Which do you prefer?

-Peff

---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 4c91e94..50dd429 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -75,6 +75,7 @@ static int ignore_packed_keep;
 static int allow_ofs_delta;
 static const char *base_name;
 static int progress = 1;
+static int all_progress;
 static int window = 10;
 static uint32_t pack_size_limit, pack_size_limit_cfg;
 static int depth = 50;
@@ -2220,7 +2221,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 			continue;
 		}
 		if (!strcmp("--all-progress", arg)) {
-			progress = 2;
+			all_progress = 1;
 			continue;
 		}
 		if (!strcmp("-q", arg)) {
@@ -2295,6 +2296,9 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 		usage(pack_usage);
 	}
 
+	if (progress && all_progress)
+		progress = 2;
+
 	/* Traditionally "pack-objects [options] base extra" failed;
 	 * we would however want to take refs parameter that would
 	 * have been given to upstream rev-list ourselves, which means

  reply	other threads:[~2009-11-23 15:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-22 14:53 how to suppress progress percentage in git-push bill lam
2009-11-23 15:00 ` Jeff King [this message]
2009-11-23 15:50   ` Petr Baudis
2009-11-23 16:43     ` Jeff King
2009-11-23 17:05       ` Petr Baudis
2009-11-23 19:28         ` Jeff King
2009-11-23 17:43       ` [PATCH] pack-objects: split implications of --all-progress from progress activation Nicolas Pitre
2009-11-23 18:12         ` Petr Baudis
2009-11-23 18:27           ` Nicolas Pitre
2009-11-23 19:04             ` Petr Baudis
2009-11-23 19:32         ` Jeff King
2009-11-23 16:56   ` how to suppress progress percentage in git-push Nicolas Pitre
2009-11-23 19:25     ` Jeff King
2009-11-23 19:40       ` Nicolas Pitre
2009-11-24  1:13     ` bill lam
2009-11-24  3:07       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091123145959.GA13138@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=cbill.lam@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=nico@fluxnic.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).