Making git push output quieter

12 messages, 7 authors, 2016-06-15 · open the first message on its own page

Making git push output quieter

From: Albert Astals Cid <hidden>
Date: 2016-06-15 22:47:09

Hi, at KDE we are starting to try to use git and one of the things that's 
bothering me is that git push is too verbose for our scripts.

We have some scripts that commit things and i get the diff of previous runs,  
if there is no diff it means all worked fine, a diff means something i have to 
look at.

Now i'm getting diffs like

-Counting objects: 23, done.
+Counting objects: 53, done.
 Delta compression using up to 2 threads.
-Compressing objects:   8% (1/12)   Compressing objects:  16% (2/12)   
Compressing objects:  25% (3/12)   Compressing objects:  33% (4/12)   
Compressing objects:  41% (5/12)   Compressing objects:  50% (6/12)   
Compressing objects:  58% (7/12)   Compressing objects:  66% (8/12)   
Compressing objects:  75% (9/12)   Compressing objects:  83% (10/12)   
Compressing objects:  91% (11/12)   Compressing objects: 100% (12/12)   
Compressing objects: 100% (12/12), done.
-Writing objects:   8% (1/12)   Writing objects:  16% (2/12)   Writing 
objects:  25% (3/12)   Writing objects:  33% (4/12)   Writing objects:  41% 
(5/12)   Writing objects:  50% (6/12)   Writing objects:  58% (7/12)   Writing 
objects:  66% (8/12)   Writing objects:  75% (9/12)   Writing objects:  83% 
(10/12)   Writing objects:  91% (11/12)   Writing objects: 100% (12/12)   
Writing objects: 100% (12/12), 1.05 KiB, done.
-Total 12 (delta 11), reused 0 (delta 0)
+Compressing objects:   3% (1/29)   Compressing objects:   6% (2/29)   
Compressing objects:  10% (3/29)   Compressing objects:  13% (4/29)   
Compressing objects:  17% (5/29)   Compressing objects:  20% (6/29)   
Compressing objects:  24% (7/29)   Compressing objects:  27% (8/29)   
Compressing objects:  31% (9/29)   Compressing objects:  34% (10/29)   
Compressing objects:  37% (11/29)   Compressing objects:  41% (12/29)   
Compressing objects:  44% (13/29)   Compressing objects:  48% (14/29)   
Compressing objects:  51% (15/29)   Compressing objects:  55% (16/29)   
Compressing objects:  58% (17/29)   Compressing objects:  62% (18/29)   
Compressing objects:  65% (19/29)   Compressing objects:  68% (20/29)   
Compressing objects:  72% (21/29)   Compressing objects:  75% (22/29)   
Compressing objects:  79% (23/29)   Compressing objects:  82% (24/29)   
Compressing objects:  86% (25/29)   Compressing objects:  89% (26/29)   
Compressing objects:  93% (27/29)   Compressing objects:  96% (28/29) 
  Compressing objects: 100% (29/29)   Compressing objects: 100% (29/29), done.
+Writing objects:   3% (1/29)   Writing objects:   6% (2/29)   Writing 
objects:  10% (3/29)   Writing objects:  13% (4/29)   Writing objects:  17% 
(5/29)   Writing objects:  20% (6/29)   Writing objects:  24% (7/29)   Writing 
objects:  27% (8/29)   Writing objects:  31% (9/29)   Writing objects:  34% 
(10/29)   Writing objects:  37% (11/29)   Writing objects:  41% (12/29)   
Writing objects:  44% (13/29)   Writing objects:  48% (14/29)   Writing 
objects:  51% (15/29)   Writing objects:  55% (16/29)   Writing objects:  62% 
(18/29)   Writing objects:  65% (19/29)   Writing objects:  68% (20/29)   
Writing objects:  72% (21/29)   Writing objects:  75% (22/29)   Writing 
objects:  79% (23/29)   Writing objects:  82% (24/29)   Writing objects:  86% 
(25/29)   Writing objects:  89% (26/29)   Writing objects:  93% (27/29)   
Writing objects:  96% (28/29)   Writing objects: 100% (29/29)   Writing 
objects: 100% (29/29), 4.46 KiB, done.
+Total 29 (delta 23), reused 0 (delta 0)
 => Syncing Gitorious... [OK]
 To git@gitorious.org:amarok/amarok.git
-   f7863f9..f4370ae  HEAD -> master
+   1a1b30f..670cb0e  HEAD -> master

That really are not a problem and are filling my diffs for no reason. We could 
redirect to > /dev/null the git push command but then i would not see if 
anything failed.

Is it possible to make git push just output data when failing? And if not do 
you think it's a worthwhile feature i can ask for? Do you have a formal way 
for feature requests?

Thanks,
  Albert

Re: Making git push output quieter

From: Pau Garcia i Quiles <hidden>
Date: 2016-06-15 22:47:09

On Tue, Aug 4, 2009 at 11:27 PM, Albert Astals Cid[off-list ref] wrote:
Hi, at KDE we are starting to try to use git and one of the things that's
bothering me is that git push is too verbose for our scripts.

We have some scripts that commit things and i get the diff of previous runs,
if there is no diff it means all worked fine, a diff means something i have to
look at.

Now i'm getting diffs like

-Counting objects: 23, done.
+Counting objects: 53, done.
 Delta compression using up to 2 threads.
-Compressing objects:   8% (1/12)   Compressing objects:  16% (2/12)
Compressing objects:  25% (3/12)   Compressing objects:  33% (4/12)
Compressing objects:  41% (5/12)   Compressing objects:  50% (6/12)
Compressing objects:  58% (7/12)   Compressing objects:  66% (8/12)
Compressing objects:  75% (9/12)   Compressing objects:  83% (10/12)
Compressing objects:  91% (11/12)   Compressing objects: 100% (12/12)
Compressing objects: 100% (12/12), done.
-Writing objects:   8% (1/12)   Writing objects:  16% (2/12)   Writing
objects:  25% (3/12)   Writing objects:  33% (4/12)   Writing objects:  41%
(5/12)   Writing objects:  50% (6/12)   Writing objects:  58% (7/12)   Writing
objects:  66% (8/12)   Writing objects:  75% (9/12)   Writing objects:  83%
(10/12)   Writing objects:  91% (11/12)   Writing objects: 100% (12/12)
Writing objects: 100% (12/12), 1.05 KiB, done.
-Total 12 (delta 11), reused 0 (delta 0)
+Compressing objects:   3% (1/29)   Compressing objects:   6% (2/29)
Compressing objects:  10% (3/29)   Compressing objects:  13% (4/29)
Compressing objects:  17% (5/29)   Compressing objects:  20% (6/29)
Compressing objects:  24% (7/29)   Compressing objects:  27% (8/29)
Compressing objects:  31% (9/29)   Compressing objects:  34% (10/29)
Compressing objects:  37% (11/29)   Compressing objects:  41% (12/29)
Compressing objects:  44% (13/29)   Compressing objects:  48% (14/29)
Compressing objects:  51% (15/29)   Compressing objects:  55% (16/29)
Compressing objects:  58% (17/29)   Compressing objects:  62% (18/29)
Compressing objects:  65% (19/29)   Compressing objects:  68% (20/29)
Compressing objects:  72% (21/29)   Compressing objects:  75% (22/29)
Compressing objects:  79% (23/29)   Compressing objects:  82% (24/29)
Compressing objects:  86% (25/29)   Compressing objects:  89% (26/29)
Compressing objects:  93% (27/29)   Compressing objects:  96% (28/29)
 Compressing objects: 100% (29/29)   Compressing objects: 100% (29/29), done.
+Writing objects:   3% (1/29)   Writing objects:   6% (2/29)   Writing
objects:  10% (3/29)   Writing objects:  13% (4/29)   Writing objects:  17%
(5/29)   Writing objects:  20% (6/29)   Writing objects:  24% (7/29)   Writing
objects:  27% (8/29)   Writing objects:  31% (9/29)   Writing objects:  34%
(10/29)   Writing objects:  37% (11/29)   Writing objects:  41% (12/29)
Writing objects:  44% (13/29)   Writing objects:  48% (14/29)   Writing
objects:  51% (15/29)   Writing objects:  55% (16/29)   Writing objects:  62%
(18/29)   Writing objects:  65% (19/29)   Writing objects:  68% (20/29)
Writing objects:  72% (21/29)   Writing objects:  75% (22/29)   Writing
objects:  79% (23/29)   Writing objects:  82% (24/29)   Writing objects:  86%
(25/29)   Writing objects:  89% (26/29)   Writing objects:  93% (27/29)
Writing objects:  96% (28/29)   Writing objects: 100% (29/29)   Writing
objects: 100% (29/29), 4.46 KiB, done.
+Total 29 (delta 23), reused 0 (delta 0)
 => Syncing Gitorious... [OK]
 To git@gitorious.org:amarok/amarok.git
-   f7863f9..f4370ae  HEAD -> master
+   1a1b30f..670cb0e  HEAD -> master

That really are not a problem and are filling my diffs for no reason. We could
redirect to > /dev/null the git push command but then i would not see if
anything failed.

Is it possible to make git push just output data when failing? And if not do
you think it's a worthwhile feature i can ask for? Do you have a formal way
for feature requests?
Have you tried redirecting only stdout to /dev/null, and keeping
stderr to yourself ? In addition to that, exit code != 0 means
something went wrong.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Making git push output quieter

From: Albert Astals Cid <hidden>
Date: 2016-06-15 22:47:09

A Dimecres, 5 d'agost de 2009, Pau Garcia i Quiles va escriure:
On Tue, Aug 4, 2009 at 11:27 PM, Albert Astals Cid[off-list ref] wrote:
quoted
Hi, at KDE we are starting to try to use git and one of the things that's
bothering me is that git push is too verbose for our scripts.

We have some scripts that commit things and i get the diff of previous
runs, if there is no diff it means all worked fine, a diff means
something i have to look at.

Now i'm getting diffs like

-Counting objects: 23, done.
+Counting objects: 53, done.
 Delta compression using up to 2 threads.
-Compressing objects:   8% (1/12)   Compressing objects:  16% (2/12)
Compressing objects:  25% (3/12)   Compressing objects:  33% (4/12)
Compressing objects:  41% (5/12)   Compressing objects:  50% (6/12)
Compressing objects:  58% (7/12)   Compressing objects:  66% (8/12)
Compressing objects:  75% (9/12)   Compressing objects:  83% (10/12)
Compressing objects:  91% (11/12)   Compressing objects: 100% (12/12)
Compressing objects: 100% (12/12), done.
-Writing objects:   8% (1/12)   Writing objects:  16% (2/12)   Writing
objects:  25% (3/12)   Writing objects:  33% (4/12)   Writing objects:
 41% (5/12)   Writing objects:  50% (6/12)   Writing objects:  58% (7/12)
  Writing objects:  66% (8/12)   Writing objects:  75% (9/12)   Writing
objects:  83% (10/12)   Writing objects:  91% (11/12)   Writing objects:
100% (12/12) Writing objects: 100% (12/12), 1.05 KiB, done.
-Total 12 (delta 11), reused 0 (delta 0)
+Compressing objects:   3% (1/29)   Compressing objects:   6% (2/29)
Compressing objects:  10% (3/29)   Compressing objects:  13% (4/29)
Compressing objects:  17% (5/29)   Compressing objects:  20% (6/29)
Compressing objects:  24% (7/29)   Compressing objects:  27% (8/29)
Compressing objects:  31% (9/29)   Compressing objects:  34% (10/29)
Compressing objects:  37% (11/29)   Compressing objects:  41% (12/29)
Compressing objects:  44% (13/29)   Compressing objects:  48% (14/29)
Compressing objects:  51% (15/29)   Compressing objects:  55% (16/29)
Compressing objects:  58% (17/29)   Compressing objects:  62% (18/29)
Compressing objects:  65% (19/29)   Compressing objects:  68% (20/29)
Compressing objects:  72% (21/29)   Compressing objects:  75% (22/29)
Compressing objects:  79% (23/29)   Compressing objects:  82% (24/29)
Compressing objects:  86% (25/29)   Compressing objects:  89% (26/29)
Compressing objects:  93% (27/29)   Compressing objects:  96% (28/29)
 Compressing objects: 100% (29/29)   Compressing objects: 100% (29/29),
done. +Writing objects:   3% (1/29)   Writing objects:   6% (2/29)  
Writing objects:  10% (3/29)   Writing objects:  13% (4/29)   Writing
objects:  17% (5/29)   Writing objects:  20% (6/29)   Writing objects:
 24% (7/29)   Writing objects:  27% (8/29)   Writing objects:  31% (9/29)
  Writing objects:  34% (10/29)   Writing objects:  37% (11/29)   Writing
objects:  41% (12/29) Writing objects:  44% (13/29)   Writing objects:
 48% (14/29)   Writing objects:  51% (15/29)   Writing objects:  55%
(16/29)   Writing objects:  62% (18/29)   Writing objects:  65% (19/29)  
Writing objects:  68% (20/29) Writing objects:  72% (21/29)   Writing
objects:  75% (22/29)   Writing objects:  79% (23/29)   Writing objects:
 82% (24/29)   Writing objects:  86% (25/29)   Writing objects:  89%
(26/29)   Writing objects:  93% (27/29) Writing objects:  96% (28/29)  
Writing objects: 100% (29/29)   Writing objects: 100% (29/29), 4.46 KiB,
done.
+Total 29 (delta 23), reused 0 (delta 0)
 => Syncing Gitorious... [OK]
 To git@gitorious.org:amarok/amarok.git
-   f7863f9..f4370ae  HEAD -> master
+   1a1b30f..670cb0e  HEAD -> master

That really are not a problem and are filling my diffs for no reason. We
could redirect to > /dev/null the git push command but then i would not
see if anything failed.

Is it possible to make git push just output data when failing? And if not
do you think it's a worthwhile feature i can ask for? Do you have a
formal way for feature requests?
Have you tried redirecting only stdout to /dev/null, and keeping
stderr to yourself ?
Everything goes to stderr.
In addition to that, exit code != 0 means
something went wrong.
I could make something with this, but is it really not something that should 
happen that errors go to stderr and regular text to stdout?

Albert

Re: Making git push output quieter

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:47:09

Albert Astals Cid [off-list ref] wrote:
A Dimecres, 5 d'agost de 2009, Pau Garcia i Quiles va escriure:
quoted
On Tue, Aug 4, 2009 at 11:27 PM, Albert Astals Cid[off-list ref] wrote:
quoted
Hi, at KDE we are starting to try to use git and one of the things that's
bothering me is that git push is too verbose for our scripts.
...
quoted
Have you tried redirecting only stdout to /dev/null, and keeping
stderr to yourself ?
Everything goes to stderr.
Sadly our use of isatty to determine if progress/verbosity should
be used is inconsistent.  pack-objects.c, which is what you are
talking about above, is using stderr to determine if progress should
be enabled, but other code like transport.c, which is used on the
client side, is using stdout.  Hence the suggestion above to redirect
stdout to /dev/null to try and shutoff the spew.

  $ git grep isatty
  builtin-commit.c:		if (isatty(0))
  builtin-config.c:			stdout_is_tty = isatty(1);
  builtin-pack-objects.c:	progress = isatty(2);
  builtin-revert.c:	if (isatty(0))
  builtin-shortlog.c:	if (!nongit && !rev.pending.nr && isatty(0))
  builtin-unpack-objects.c:	quiet = !isatty(2);
  color.c:		stdout_is_tty = isatty(1);
  compat/winansi.c:	if (!isatty(fileno(stream)))
  compat/winansi.c:	if (!isatty(fileno(stream)))
  pack-redundant.c:	if (!isatty(0)) {
  pager.c:	if (!isatty(1))
  pager.c:	if (isatty(2))
  transport.c:	args.no_progress = args.quiet || (!transport->progress && !isatty(1));
  wt-status.c:	 * will have checked isatty on stdout).

I'm thinking this might be a reasonable patch to apply, Junio/Nico?

--8<--
pack-objects: Display progress only if stdout is tty

Client transports underneath git fetch display progress output only
if stdout is a tty, allowing redirection of stdout to /dev/null (or
a pipe) to silence progress but still report actual errors on stderr.

Doing the same in pack-objects means push, bundle creation and
repack can use the same trick to silence noisy progress progress,
but still obtain real errors.

Signed-off-by: Shawn O. Pearce <redacted>
---
 builtin-pack-objects.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 961b639..0b9234a 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -2110,7 +2110,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 	if (!pack_compression_seen && core_compression_seen)
 		pack_compression_level = core_compression_level;
 
-	progress = isatty(2);
+	progress = isatty(1);
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 
-- 
1.6.4.70.g9c084


-- 
Shawn.

Re: Making git push output quieter

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:47:09

On Wed, 5 Aug 2009, Shawn O. Pearce wrote:
quoted hunk
Albert Astals Cid [off-list ref] wrote:
quoted
A Dimecres, 5 d'agost de 2009, Pau Garcia i Quiles va escriure:
quoted
On Tue, Aug 4, 2009 at 11:27 PM, Albert Astals Cid[off-list ref] wrote:
quoted
Hi, at KDE we are starting to try to use git and one of the things that's
bothering me is that git push is too verbose for our scripts.
...
quoted
quoted
Have you tried redirecting only stdout to /dev/null, and keeping
stderr to yourself ?
Everything goes to stderr.
Sadly our use of isatty to determine if progress/verbosity should
be used is inconsistent.  pack-objects.c, which is what you are
talking about above, is using stderr to determine if progress should
be enabled, but other code like transport.c, which is used on the
client side, is using stdout.  Hence the suggestion above to redirect
stdout to /dev/null to try and shutoff the spew.

  $ git grep isatty
  builtin-commit.c:		if (isatty(0))
  builtin-config.c:			stdout_is_tty = isatty(1);
  builtin-pack-objects.c:	progress = isatty(2);
  builtin-revert.c:	if (isatty(0))
  builtin-shortlog.c:	if (!nongit && !rev.pending.nr && isatty(0))
  builtin-unpack-objects.c:	quiet = !isatty(2);
  color.c:		stdout_is_tty = isatty(1);
  compat/winansi.c:	if (!isatty(fileno(stream)))
  compat/winansi.c:	if (!isatty(fileno(stream)))
  pack-redundant.c:	if (!isatty(0)) {
  pager.c:	if (!isatty(1))
  pager.c:	if (isatty(2))
  transport.c:	args.no_progress = args.quiet || (!transport->progress && !isatty(1));
  wt-status.c:	 * will have checked isatty on stdout).

I'm thinking this might be a reasonable patch to apply, Junio/Nico?

--8<--
pack-objects: Display progress only if stdout is tty

Client transports underneath git fetch display progress output only
if stdout is a tty, allowing redirection of stdout to /dev/null (or
a pipe) to silence progress but still report actual errors on stderr.

Doing the same in pack-objects means push, bundle creation and
repack can use the same trick to silence noisy progress progress,
but still obtain real errors.

Signed-off-by: Shawn O. Pearce <redacted>
---
 builtin-pack-objects.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 961b639..0b9234a 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -2110,7 +2110,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 	if (!pack_compression_seen && core_compression_seen)
 		pack_compression_level = core_compression_level;
 
-	progress = isatty(2);
+	progress = isatty(1);
Doesn't this break progress reporting on a push since stdout is never a 
tty in that case?  Same issue on a fetch although in that case the 
progress level is provided explicitly by the caller.


 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 
-- 
1.6.4.70.g9c084


-- 
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Making git push output quieter

From: Jeff King <hidden>
Date: 2016-06-15 22:47:09

On Wed, Aug 05, 2009 at 03:51:27PM -0400, Nicolas Pitre wrote:
quoted
-	progress = isatty(2);
+	progress = isatty(1);
Doesn't this break progress reporting on a push since stdout is never a 
tty in that case?  Same issue on a fetch although in that case the 
progress level is provided explicitly by the caller.
It also doesn't entirely fix the original poster's problem. There are
actually two outputs: the progress report and the push status. I think
we actually just want a "--quiet" flag here which is passed along to
pack-objects, and which suppresses the push status. Patch series
to follow:

  1/3: push: add --quiet flag
  2/3: transport: pass "quiet" flag to pack-objects
  3/3: transport: don't show push status if --quiet is given

-Peff

[RFC/PATCH 1/3] push: add --quiet flag

From: Jeff King <hidden>
Date: 2016-06-15 22:47:09

Some transports produce output even without "--verbose"
turned on. This provides a way to tell them to be more
quiet (whereas simply redirecting might lose error
messages).

Signed-off-by: Jeff King <redacted>
---
Missing tests and docs still.

It may be a bit weird, but you can actually say "--quiet --verbose" and
they don't exactly cancel each other. But it can actually be useful to
say "don't show me the ref status unless there is an error (--quiet), in
which case show me the entire table (--verbose)".

 builtin-push.c |    1 +
 transport.h    |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 1d92e22..bc0c91a 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -168,6 +168,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
 	const char *repo = NULL;	/* default repository */
 
 	struct option options[] = {
+		OPT_BIT('q', "quiet", &flags, "be quiet", TRANSPORT_PUSH_QUIET),
 		OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
 		OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
 		OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
diff --git a/transport.h b/transport.h
index 51b5397..f1d3ebf 100644
--- a/transport.h
+++ b/transport.h
@@ -36,6 +36,7 @@ struct transport {
 #define TRANSPORT_PUSH_MIRROR 8
 #define TRANSPORT_PUSH_VERBOSE 16
 #define TRANSPORT_PUSH_PORCELAIN 32
+#define TRANSPORT_PUSH_QUIET 64
 
 /* Returns a transport suitable for the url */
 struct transport *transport_get(struct remote *, const char *);
-- 
1.6.4.218.g9f65c.dirty

[PATCH 2/3] transport: pass "quiet" flag to pack-objects

From: Jeff King <hidden>
Date: 2016-06-15 22:47:09

When pushing over the git protocol, pack-objects gives
progress reports about the pack being sent. If "push" is
given the --quiet flag, it now passes "-q" to pack-objects,
suppressing this output.

Signed-off-by: Jeff King <redacted>
---
 builtin-send-pack.c |    3 +++
 send-pack.h         |    1 +
 transport.c         |    1 +
 3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 47fb9f7..37e528e 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -44,6 +44,7 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
 		NULL,
 		NULL,
 		NULL,
+		NULL,
 	};
 	struct child_process po;
 	int i;
@@ -53,6 +54,8 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
 		argv[i++] = "--thin";
 	if (args->use_ofs_delta)
 		argv[i++] = "--delta-base-offset";
+	if (args->quiet)
+		argv[i++] = "-q";
 	memset(&po, 0, sizeof(po));
 	po.argv = argv;
 	po.in = -1;
diff --git a/send-pack.h b/send-pack.h
index 1d7b1b3..8b3cf02 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -3,6 +3,7 @@
 
 struct send_pack_args {
 	unsigned verbose:1,
+		quiet:1,
 		send_mirror:1,
 		force_update:1,
 		use_thin_pack:1,
diff --git a/transport.c b/transport.c
index 8a42e76..2d0c491 100644
--- a/transport.c
+++ b/transport.c
@@ -878,6 +878,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
 	args.force_update = !!(flags & TRANSPORT_PUSH_FORCE);
 	args.use_thin_pack = data->thin;
 	args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
+	args.quiet = !!(flags & TRANSPORT_PUSH_QUIET);
 	args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
 
 	ret = send_pack(&args, data->fd, data->conn, remote_refs,
-- 
1.6.4.218.g9f65c.dirty

[PATCH 3/3] transport: don't show push status if --quiet is given

From: Jeff King <hidden>
Date: 2016-06-15 22:47:09

When --quiet is given, the user generally only wants to see
errors. So let's suppress printing the ref status table
unless there is an error, in which case we print out the
whole table.

Signed-off-by: Jeff King <redacted>
---
We could get fancier here and print out only the refs with errors if
quiet is given, but I went for simplicity.

 transport.c |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 2d0c491..afec5b7 100644
--- a/transport.c
+++ b/transport.c
@@ -667,6 +667,21 @@ static int fetch_refs_via_pack(struct transport *transport,
 	return (refs ? 0 : -1);
 }
 
+static int push_had_errors(struct ref *ref)
+{
+	for (; ref; ref = ref->next) {
+		switch (ref->status) {
+		case REF_STATUS_NONE:
+		case REF_STATUS_UPTODATE:
+		case REF_STATUS_OK:
+			break;
+		default:
+			return 1;
+		}
+	}
+	return 0;
+}
+
 static int refs_pushed(struct ref *ref)
 {
 	for (; ref; ref = ref->next) {
@@ -996,6 +1011,7 @@ int transport_push(struct transport *transport,
 		struct ref *local_refs = get_local_heads();
 		int match_flags = MATCH_REFS_NONE;
 		int verbose = flags & TRANSPORT_PUSH_VERBOSE;
+		int quiet = flags & TRANSPORT_PUSH_QUIET;
 		int porcelain = flags & TRANSPORT_PUSH_PORCELAIN;
 		int ret;
 
@@ -1011,7 +1027,9 @@ int transport_push(struct transport *transport,
 
 		ret = transport->push_refs(transport, remote_refs, flags);
 
-		print_push_status(transport->url, remote_refs, verbose | porcelain, porcelain);
+		if (!quiet || push_had_errors(remote_refs))
+			print_push_status(transport->url, remote_refs,
+					verbose | porcelain, porcelain);
 
 		if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
 			struct ref *ref;
-- 
1.6.4.218.g9f65c.dirty

Re: [PATCH 3/3] transport: don't show push status if --quiet is given

From: Sverre Rabbelier <hidden>
Date: 2016-06-15 22:47:09

Heya,

On Wed, Aug 5, 2009 at 13:23, Jeff King[off-list ref] wrote:
+       for (; ref; ref = ref->next) {
+               switch (ref->status) {
+               case REF_STATUS_NONE:
+               case REF_STATUS_UPTODATE:
+               case REF_STATUS_OK:
+                       break;
+               default:
+                       return 1;
+               }
+       }
Is my C getting sloppy or is this a non-looping loop? AFAICS it either
return 1's on the first run, or breaks?

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH 3/3] transport: don't show push status if --quiet is given

From: Avery Pennarun <hidden>
Date: 2016-06-15 22:47:09

On Wed, Aug 5, 2009 at 8:27 PM, Sverre Rabbelier[off-list ref] wrote:
On Wed, Aug 5, 2009 at 13:23, Jeff King[off-list ref] wrote:
quoted
+       for (; ref; ref = ref->next) {
+               switch (ref->status) {
+               case REF_STATUS_NONE:
+               case REF_STATUS_UPTODATE:
+               case REF_STATUS_OK:
+                       break;
+               default:
+                       return 1;
+               }
+       }
Is my C getting sloppy or is this a non-looping loop? AFAICS it either
return 1's on the first run, or breaks?
The "break" in this case breaks out of the switch, not the for.

Avery

Re: [PATCH 3/3] transport: don't show push status if --quiet is given

From: Sverre Rabbelier <hidden>
Date: 2016-06-15 22:47:09

Heya,

On Wed, Aug 5, 2009 at 13:29, Avery Pennarun[off-list ref] wrote:
quoted
Is my C getting sloppy or is this a non-looping loop? AFAICS it either
return 1's on the first run, or breaks?
The "break" in this case breaks out of the switch, not the for.
Ouch, painfull, my C _IS_ getting sloppy :(.

-- 
Cheers,

Sverre Rabbelier
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help