git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Steffen Prohaska <prohaska@zib.de>
Cc: Git Mailing List <git@vger.kernel.org>,
	Carl Worth <cworth@cworth.org>,
	"Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: A tour of git: the basics (and notes on some unfriendly messages)
Date: Sat, 29 Sep 2007 15:25:00 -0700	[thread overview]
Message-ID: <7vlkapjeir.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <E5C688F2-4A8D-402A-9757-5007BE4A8B25@zib.de> (Steffen Prohaska's message of "Sat, 29 Sep 2007 23:48:25 +0200")

Steffen Prohaska <prohaska@zib.de> writes:

> Quite often git prints a lot of very technical information that
> is not very interesting as long as things succeed without error.
> Some examples are
> - git fetch (see above)

Probably.

> - git rebase: prints a lot of details that I'm not interested in
>   unless the rebase fails.

Yes.  Most of the clutter is coming from "am" which also should
be squelched.

Saying

	Switched to branch <blah>

is good when the branch to rebase is specified.

	"HEAD is now at ..."
is not useful -- it is a side effect of rewinding the head to
the --onto commit.

	<blank line>
        Applying <patch subject>
	<blank line>
        Wrote tree <tree object>
        Committed: <commit object>

are coming from "am" for each patch.  We could squelch these
into just one "Applying <patch subject>" and nothing else, which
would also help making "am" quieter.

> - git push: prints updates of remote heads. A message about
>   failing to update a remote head may get lost.

Please do not remove the report of successful update, as people
often say "git push" or "git push $there" without explicitly
saying which refs to push.  When pushing out to publish, I say
"git push ko" (to mean k.org) and I _want_ my positive feedback.

> - git merge: the fact that a merge is a fast forward merge gets
>   printed at the very top, followed by (often a lot of) diffstat.
>   I know diffstat can help to judge if the merge did what you
>   expected. But even more important is the fact that the merge
>   was just a fast forward, which may get buried under lots of output.

I do not think fast-forwardness is particularly interesting.  If
you find fast-forwardness interesting, I suspect you would even
want to know what _your_ change that were not in the other side
of the merge, which is something that we do not even report
right now.

> Maybe git should become more quiet, as other unix tools are, and
> per default only report problems. Technical details and progress
> could be requested explicitly by '--verbose' or similar.

I'd agree with this sentiment in principle, and many of the
things you propose to remove above fall into the "unnecessary
clutter" category.  But some of the existing output fall into
the "necessary info" category --- diffstart after merge and
report of successful remote ref updates are such things, so we
should be careful not to go overboard.

  reply	other threads:[~2007-09-29 22:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28 23:07 A tour of git: the basics (and notes on some unfriendly messages) Carl Worth
2007-09-29  0:00 ` Shawn O. Pearce
2007-09-29  0:49   ` Johannes Schindelin
2007-09-29  7:44     ` Steffen Prohaska
2007-09-29 15:06       ` Johannes Schindelin
2007-09-29 16:06         ` Steffen Prohaska
2007-09-29 16:05           ` [PATCH] WinGit: included /bin/start in the installer Steffen Prohaska
2007-09-29 16:05             ` [PATCH] WinGit: include html pages from official git.git's html branch Steffen Prohaska
2007-09-29 20:50               ` Johannes Schindelin
2007-09-29 22:13                 ` Junio C Hamano
2007-09-29 23:23                   ` Johannes Schindelin
2007-09-30  8:19                     ` Steffen Prohaska
2007-09-29  9:01   ` A tour of git: the basics (and notes on some unfriendly messages) Pierre Habouzit
2007-09-29 10:45     ` [RFC] patch series to sketch a less verbose and frightening output Pierre Habouzit
2007-09-29 10:49       ` Pierre Habouzit
     [not found]       ` <1191062758-30631-2-git-send-email-madcoder@debian.org>
2007-09-29 14:33         ` [PATCH 1/4] Rework progress module so that it uses less screen lines, with progress bars Nicolas Pitre
2007-09-29 16:07           ` Pierre Habouzit
2007-09-30 12:45     ` A tour of git: the basics (and notes on some unfriendly messages) Wincent Colaiuta
2007-09-30 13:49       ` Pierre Habouzit
2007-09-30 14:31         ` Wincent Colaiuta
2007-09-29 21:48   ` Steffen Prohaska
2007-09-29 22:25     ` Junio C Hamano [this message]
2007-09-30  8:15       ` Steffen Prohaska
2007-09-30 10:17         ` Junio C Hamano
2007-09-30 12:44         ` Johannes Schindelin
2007-09-30 13:41           ` Steffen Prohaska
2007-09-29  0:45 ` Junio C Hamano
2007-09-30  3:38   ` Carl Worth
2007-09-30  3:38   ` Carl Worth
2007-09-29  5:32 ` Nguyen Thai Ngoc Duy

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=7vlkapjeir.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=cworth@cworth.org \
    --cc=git@vger.kernel.org \
    --cc=prohaska@zib.de \
    --cc=spearce@spearce.org \
    /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).