From: Peter Vereshagin <peter@vereshagin.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: 'show' pretty %B without a diff
Date: Tue, 21 Dec 2010 14:04:47 +0300 [thread overview]
Message-ID: <20101221104641.GA8600@external.screwed.box> (raw)
In-Reply-To: <7v4oa8cobn.fsf@alter.siamese.dyndns.org>
You know St. Peter won't call my name, Junio!
2010/12/20 10:05:16 -0800 Junio C Hamano <gitster@pobox.com> => To Peter Vereshagin :
JCH> > JCH> Especially if you are doing a script, you probably should be using
JCH> > JCH> "cat-file commit" anyway, no?
JCH> >
JCH> > cat-file doesn't seem to support formatting option?
JCH>
JCH> That is exactly why I suggested "cat-file", as you are scripting. We
JCH> reserve the right to change the human-visible formatting output from
JCH> Porcelain commands like "show" any time to make it "prettier" (we may
JCH> start coloring strings that look like object names in the commit log
JCH> message in "git show" output, for example), while giving scripts more
JCH> stable output through the plumbing commands like "cat-file" so that they
JCH> can parse and process without having to worry about the output format
JCH> changing under them.
IMHO there is a difference between coloring the output and digging the data
from the storage, the what is the %B is about for me.
In a context of a script I believe every scriptwriter should expect a function
like get_comment_raw( $commitId ) than to worry about command output stability.
This is just where I believe the Git.pm will get closer to. One day.
No matter if such a function should look more like this: $gitObject->newById(
$commitId )->showDetails( '%B' ); . The I/O operations for this I believe
should be the storage files opening and reading, thus the piping from commands
like 'cat-file' is only the temporary solution.
Isn't it?
For the applications such an API approach is just more expectable than
porcelain versus plumbing commands. Although this requires care about features
like the particular (e.g., Perl) bindings, it is a must for the applications
efficiency which is a sense for a modern web at least.
JCH> If your script is _not_ parsing the git command output, but is just
JCH> blindly spewing it out to the invoking user, it is Ok to use "show",
JCH> though. Check "-s" option to the "show" command in that case.
"show" command doesn't seem to have "-s" switch. Skip it up though ;-)
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org
next prev parent reply other threads:[~2010-12-21 11:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-20 7:38 'show' pretty %B without a diff Peter Vereshagin
2010-12-20 9:05 ` Junio C Hamano
2010-12-20 11:12 ` Peter Vereshagin
2010-12-20 18:05 ` Junio C Hamano
2010-12-21 11:04 ` Peter Vereshagin [this message]
2010-12-21 12:56 ` Jakub Narebski
2010-12-21 18:04 ` Jonathan Nieder
2010-12-21 20:27 ` Martin Langhoff
2010-12-21 20:40 ` Jakub Narebski
2010-12-22 18:33 ` peter
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=20101221104641.GA8600@external.screwed.box \
--to=peter@vereshagin.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).