Subject: Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet

From: Junio C Hamano <[email-masked]>
Date: Thu, 23 Jul 2015 10:06:28 -0700

Junio C Hamano <[email-masked]> writes:

> Sebastian Schuberth <[email-masked]> writes:
>
>> Well, from a user's perspective it does not matter which part of the
>> internal implementation of diff-tree is responsible for printing that
>> single line,...
>
> That is not "internal implementation", but "logically separate
> parts".  View it more like "'git show -s' does squelch the diff part
> but does not squelch the log output".  After all, a single commit form
> of 'diff-tree' is a degenerate use case of feeding a single commit
> to 'diff-tree --stdin' from its standard input, which is a rough
> plumbing-level equivalent of 'show'.
>
> Documenting the behaviour correctly is the best thing you could do
> at this point, as this is one of the oldest part of the system that
> existing scripts would rely on.

Having said that.

Existing scripts by definition would not be using a new option you
will invent that used not to be a valid one.  So that would be one
way that you can shorten your script without breaking other people.

If we were living in an ideal world equipped with a time machine, I
would redesign "git diff-tree $commit" so that it does not show the
commit object name in its output at all, with or without "--quiet".

In "git rev-list ... | git diff-tree --stdin" output, the commit
object name is absolutely necessary, with or without --quiet, as it
serves as the sign that the output switched to talk about a
different commit.  But the case that feeds a single commit to the
command, used as a poor-man's "git show $commit", does not need
one---the caller knows exactly which commit the output is about.  It
is an unfortunate historical accident that a single commit usage is
defined to be a degenerate case of feeding a sequence of commits to
the command and the length of the sequence happens to be one.

But we do not live in an ideal world.