git rev-list with --name-status?

git rev-list with --name-status?

[skillzero]

Is there a way to print the equivalent of --name-status with git
rev-list? The post-receive script that comes with git for sending
comment emails does this to generate the commit log:

git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
	git rev-list --pretty --stdin $oldrev..$newrev

I'd like to also include the output of --name-status so the email
shows which files were changed by each commit (rather than just a
summary at the end since our pushes sometimes have a lot of commits in
them).

git rev-list doesn't seem to support --name-status and git log doesn't
seem to support --stdin. Is there a better way to do what I want?

Re: git rev-list with --name-status?

[Junio C Hamano]

skillzero@gmail.com writes:

> I'd like to also include the output of --name-status so the email
> shows which files were changed by each commit (rather than just a
> summary at the end since our pushes sometimes have a lot of commits in
> them).
>
> git rev-list doesn't seem to support --name-status and git log doesn't
> seem to support --stdin. Is there a better way to do what I want?

The plumbing rev-list never runs diff internally.

Depending on what you want, "git log --stat" or "git log --name-only" or
even "git log --name-status -B -C" may serve you nicely.

"Depending on what you want" is the key phrase that indicates that what
you are asking for would be most likely found in Porcelains, not plumbing.

Even though there is not much reason to _avoid_ using "log" these days,
you could do your own scripting for whatever reason; perhaps you feel like
it would be a more macho thing to do (which isn't), perhaps you want more
customization than options supported by the stock "log" Porcelain gives
you.

In olden days, people scripted around plumbing, partly because the
Porcelains were implemented that way, and partly because the choices the
Porcelains back then gave you was limited than what we have now.  Your
script may look like this:

    git-rev-list --parents $range |
    while read commit parents
    do
            ... do whatever you want with them ...
    done

or

    git-rev-list --pretty --parents $range |
    perl -e '
    	while (<>) {
        	if (/^commit /../^$/) {
			if (/^commit (\S+)(.*)?/) {
				... we have a new commit; flush what
                                ... you accumulated for the previous one.
				... and prepare for this commit.
				... $1 is the commit, $2 has parents you
                                ... can further split
                        }
			... do "header" things here ...
                        next;
                }
                s/^    //;
                ... do "log" things here ...
	}
        ... flush what you accumulated for the last commit.
    '                

Re: git rev-list with --name-status?

[demerphq]

2008/12/24  <skillzero@gmail.com>:
> Is there a way to print the equivalent of --name-status with git
> rev-list? The post-receive script that comes with git for sending
> comment emails does this to generate the commit log:
>
> git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
>        git rev-list --pretty --stdin $oldrev..$newrev
>
> I'd like to also include the output of --name-status so the email
> shows which files were changed by each commit (rather than just a
> summary at the end since our pushes sometimes have a lot of commits in
> them).
>
> git rev-list doesn't seem to support --name-status and git log doesn't
> seem to support --stdin. Is there a better way to do what I want?

I wrote the following shell script function which you can add to your
post-receive-mail script. Any git rev-list --pretty statements there
can have the --pretty removed and have their output redirected to
this, and you get what you want. An  existing function changed to use
it follows. Theres probably prettier ways to do this, but hope it
helps. Id send a diff of the script as a whole except that its full of
other likely irrelevent changes.

Yves

# show_log_for_sha1s_on_std()
#
# take a list of sha1's on STDIN and print out their logs.
#
# if there are
#
# 0 commits output a notice saying there no changes in this update
#
# 1 commits - show the log only
#
# >1 commits - show log with --name-status output (list of files with
M/D/A type tags
# next to them for Modified Deleted and Added)
#
# This partly exists because we can't use --name-status with rev-list, and
# because we cant use --stdin with git log (even tho the docs might say
# otherwise in older gits). Although since we count SHA1's we can also do some
# special stuff like dealing with the 0/1/N commits differently.

show_log_for_sha1s_on_stdin()
{
                perl -e'
                        chomp(my @sha1= <>);
                        if (!@sha1) {
                                print "No new revisions added by this update\n";
                        }
                        else {
                            my $ns= @sha1 > 1 ? " --name-status" : "";
                            for my $idx (0..$#sha1) {
                                print $idx ? "\n" :  "" ,
                                      `git-log --pretty$ns -1 $sha1[$idx]`;
                                }
                        }
                '
}

generate_create_branch_email()
{
        # This is a new branch and so oldrev is not valid
        echo "        at  $newrev ($newrev_type)"
        echo ""

        echo $LOGBEGIN
        # This shows all log entries that are not already covered by
        # another ref - i.e. commits that are now accessible from this
        # ref that were previously not accessible
        # (see generate_update_branch_email for the explanation of this
        # command)
        git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
        git rev-list --stdin $newrev | show_log_for_sha1s_on_stdin
        echo $LOGEND
}

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: git rev-list with --name-status?

[Junio C Hamano]

skillzero@gmail.com writes:

> Is there a way to print the equivalent of --name-status with git
> rev-list? The post-receive script that comes with git for sending
> comment emails does this to generate the commit log:
>
> git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> 	git rev-list --pretty --stdin $oldrev..$newrev

I should have noticed this earlier.

You seem to be referring to contrib/hooks/post-receive-email as "The
script that comes with git".  It does have customization possibility
already implemented and documented:

    hooks.showrev
       The shell command used to format each revision in the email, with
       "%s" replaced with the commit id.  Defaults to "git rev-list -1
       --pretty %s", displaying the commit id, author, date and log
       message.  To list full patches separated by a blank line, you
       could set this to "git show -C %s; echo".

One of my day-job repositories has:

    [hooks]
            mailinglist = some-secret-project@day-job-domain.com
            emailprefix = "[SOME-SECRET-PROJECT GIT] "
            showrev = "git show --stat %s; echo"

I think you can use "git show --name-status %s; echo" instead, if you like
the --name-status output.

Re: git rev-list with --name-status?

[skillzero]

On Thu, Dec 25, 2008 at 10:59 AM, Junio C Hamano <gitster@pobox.com> wrote:

> You seem to be referring to contrib/hooks/post-receive-email as "The
> script that comes with git".  It does have customization possibility
> already implemented and documented:
>
>    hooks.showrev
>       The shell command used to format each revision in the email, with
>       "%s" replaced with the commit id.  Defaults to "git rev-list -1
>       --pretty %s", displaying the commit id, author, date and log
>       message.  To list full patches separated by a blank line, you
>       could set this to "git show -C %s; echo".
>
> ...
>
> I think you can use "git show --name-status %s; echo" instead, if you like
> the --name-status output.

Thanks, that's perfect. I was using an older version of
contrib/hooks/post-receive-email that didn't have hooks.showrev so I
didn't realize it already had support for what I wanted.