From: Junio C Hamano <gitster@pobox•com>
To: Sebastian Schuberth <sschuberth@gmail•com>
Cc: Git Mailing List <git@vger•kernel.org>
Subject: Re: [PATCH] diff-tree: do not show the sha1 of the given head with --quiet
Date: Thu, 23 Jul 2015 10:06:28 -0700 [thread overview]
Message-ID: <xmqq615aregb.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqegjyrfrq.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Thu, 23 Jul 2015 09:38:01 -0700")
Junio C Hamano <gitster@pobox•com> writes:
> Sebastian Schuberth <sschuberth@gmail•com> 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.
next prev parent reply other threads:[~2015-07-23 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 9:29 [PATCH] diff-tree: do not show the sha1 of the given head with --quiet Sebastian Schuberth
2015-07-22 11:42 ` Johannes Schindelin
2015-07-22 11:56 ` [PATCH v2] " Sebastian Schuberth
2015-07-22 20:32 ` [PATCH] " Junio C Hamano
2015-07-23 7:06 ` Sebastian Schuberth
2015-07-23 16:38 ` Junio C Hamano
2015-07-23 17:06 ` Junio C Hamano [this message]
2015-07-23 20:13 ` Sebastian Schuberth
2015-07-23 18:08 ` Jeff King
2015-07-23 19:39 ` Junio C Hamano
2015-07-23 20:19 ` Sebastian Schuberth
2015-07-23 20:43 ` Junio C Hamano
2015-07-23 20:02 ` Sebastian Schuberth
2015-07-24 6:56 ` 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=xmqq615aregb.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=sschuberth@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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