'show' pretty %B without a diff

Hey Mr(s) git show some good to me!

I'd like to output a comment in my script. Thus, I try: 'git show --format="%B" commitId' There is always diff in the end of the output. No matter what format I specify, even when it is empty. How can I avoid diff output in the 'git show'? Thank you.

73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627) -- http://vereshagin.org

Peter Vereshagin <peter@vereshagin.org> writes:

The best answer to "avoid" it would be not to use "git show"; after all the command is about showing the change it introduces when it is used on a commit.

Especially if you are doing a script, you probably should be using "cat-file commit" anyway, no?

Hey Mr(s) Junio show some good to me! 2010/12/20 01:05:17 -0800 Junio C Hamano <gitster@pobox.com> => To Peter Vereshagin :

JCH> > I'd like to output a comment in my script. JCH> > Thus, I try: 'git show --format="%B" commitId' JCH> > There is always diff in the end of the output. No matter what format I specify, even when it is empty. JCH> > How can I avoid diff output in the 'git show'? JCH> JCH> The best answer to "avoid" it would be not to use "git show"; after all JCH> the command is about showing the change it introduces when it is used on a JCH> commit. JCH> JCH> Especially if you are doing a script, you probably should be using JCH> "cat-file commit" anyway, no?

cat-file doesn't seem to support formatting option? Also, it outputs 4 more unwanted fields than just the %B... used with the -p is the only what looks like the what I asked. Is it appropriate in a general case to skip the everything on that output till the first empty line? cause I'm not sure those are always 4 and not-empty lines.

Thanks anyway, it's just better than nothing. Although I wish the -p for cat-file to behave like the simlar-minded --pretty of the 'show'. (=

Or the Git.pm just to have a functionality to get the %B of the commit.

73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627) -- http://vereshagin.org

Peter Vereshagin <peter@vereshagin.org> writes:

That is exactly why I suggested "cat-file", as you are scripting. We reserve the right to change the human-visible formatting output from Porcelain commands like "show" any time to make it "prettier" (we may start coloring strings that look like object names in the commit log message in "git show" output, for example), while giving scripts more stable output through the plumbing commands like "cat-file" so that they can parse and process without having to worry about the output format changing under them.

If your script is _not_ parsing the git command output, but is just blindly spewing it out to the invoking user, it is Ok to use "show", though. Check "-s" option to the "show" command in that case.

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

Peter Vereshagin <peter@vereshagin.org> writes:

Hmmm... true, unfortunately it is described in hidden corner: when git-show is used to display commits, it accepts diff family options... including `-s' described in git-diff-tree manpage:

  -s::
        By default, 'git diff-tree --stdin' shows differences,
        either in machine-readable form (without '-p') or in patch
        form (with '-p').  This output can be suppressed.  It is
        only useful with '-v' flag.

  -v::
        This flag causes 'git diff-tree --stdin' to also show
        the commit message before the differences.

I guess that `-s' should be present also in git-show manpage.

There is also `git log -1` (or `git log -1 --no-walk` for paranoid).

Jakub Narebski wrote:

It is mentioned in the examples section since v1.7.3.3~42. That manpage needs a rework in general, though.

Or even "git diff-tree -s --pretty=%B <commit>" if that is the intent.

As much as a person might dislike plumbing, plumbing is git's current stable API. Maybe the libgit2 project will come up with something better[1]. Until then, I am happy to have some commands that avoid user-friendliness niceties (like implied "HEAD") that would create pitfalls when scripting.

Maybe it would be worth adding a plumbing example under the EXAMPLES for each porcelain? I can see that having to learn a second set of commands might make life hard (like scripting in the bourne shell when one is a csh user).

[1] I am pessimistic since that project has not made itself very visible for feedback from the git list or submitted changes back to git. It would be great to be surprised.

On Tue, Dec 21, 2010 at 1:04 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Since porcelain went to C, one thing I often do is checkout really old versions of git to see exactly what the shell version of a particular command did .

That way, I get a much better understanding of how a certain action is done at the plumbing level; complement that with the documentation for reference, and I'm 99% done.

Maybe that helps someone .

cheers,

m

Martin Langhoff <martin.langhoff@gmail.com> writes:

You can always browse 'contrib/examples/' instead.

On Tue, 21 Dec 2010 12:04:59 -0600, Jonathan Nieder <jrnieder@gmail.com> wrote:

Exactly the what I asked for. Thanks!