Re: [PATCH] Make commit, cherry-pick and revert more silent.

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2008, 22:52 UTC
Message-ID: <7vir2636tq.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1199634201-26013-1-git-send-email-g2p.code@gmail.com>

Gabriel <g2p.code@gmail.com> writes:

> Commit now obeys --quiet more.
> Cherry-pick and revert call commit as --quiet.
> Prevents us from displaying working-tree status once or even twice.

Well, you also need to defend that it is a good thing not to show the status information during cherry-pick or revert much better, especially when we are this late into the -rc cycle.

Show 12 quoted lines

> diff --git a/builtin-commit.c b/builtin-commit.c
> index 73f1e35..96ace77 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -759,7 +759,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>  
>  	if (!prepare_log_message(index_file, prefix) && !in_merge &&
>  	    !allow_empty && !(amend && is_a_merge(head_sha1))) {
> -		run_status(stdout, index_file, prefix, 0);
> +		fprintf(stderr, "There are no changes, not committing.\n");
> +		if (!quiet)
> +			run_status(stdout, index_file, prefix, 0);

Especially if you are introducing a change to a command you do not even mention in the topic line of the patch.

Having said that, I think it is a good change, if the UI change to cherry-pick and revert only triggers when the operation did not have any effect.

It is much harder to know for a user if a cherry-pick or revert will result in such a situation before actually running these commands, than when making his own commit. And the status output from underlying git-commit only distracts him by obscuring the punch-line "nothing added to commit", which is currently the only clue. I'd agree that is a UI bug in the current implementation of cherry-pick/revert.

So a more convincing presentation would be:

 * A single patch to "git commit".  The commit log message would
   read:

   When there is nothing to commit, "git commit --quiet" still
   shows the status output before saying "nothing added to
   commit...".  This patch makes it less verbose.

 * Another patch on top of it that runs "git commit" with
   the "--quiet" option from cherry-pick and revert.  The commit
   log message would read:

   When cherry-pick or revert results in no change at all
   (e.g. the user cherry-picked an ancestor of the current
   commit), the command correctly refuses to create a new
   commit, but it responds by showing the status output and
   "nothing added to commit" message.

   This is a very roundabout way to tell the user that the
   cherry-pick or revert was unnecessary.  Especially because it
   is much harder to know for a user if a cherry-pick or revert
   will result in such a situation before actually running these
   commands, than when making his own commit.

   This patch makes cherry-pick and revert call "git commit"
   with --quiet option to make the output much less confusing.

After I wrote all that, I realized that the patch is not acceptable as is.

Why?

This makes a successful cherry-pick way too silent. With your patch, we will see:

 * "Auto-merged ..." messages that shows what paths are affected
   by the cherry-pick/revert (which I do not think we would want
   to squelch),

 * "Finished one cherry-pick."

But we will lose the "Created commit ...: <msg>" and "<num> files changed..." summary, neither of which we would want to lose.

Also sign your patch (see Documentation/SubmittingPatches), please, when you try the second round.

Thanks.