mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Christoph Michelbach <>
Subject: Re: Documentation of post-receive hook
Date: Fri, 17 Nov 2017 12:24:24 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Junio C. Hamano's message of "Fri, 17 Nov 2017 10:41:21 +0900")

Junio C Hamano <> writes:

>>     This hook is invoked by 'git-receive-pack' on the remote repository,
>>     which happens when a 'git push' is done on a local repository and
>>     successfully transfers at least 1 commit.
> I am not sure "at least 1 commit" is a good phrase to use here.
> There are transfer that sends objects but no commit object, and the
> above makes it sound as if such a transfer will not trigger the
> hook.  Would
> 	This hook is run by 'git receive-pack' on the remote
> 	repository, after it receives objects sent by 'git push'.
> be clear enough to teach readers that a no-op push that recieve-pack
> does not receive any object does not trigger the hook?

Actually I take this back.  Your original observation "only when at
least one commit is transferred" is not even correct.

You can try what I just tried to make sure:

        $ git clone --no-local . ../victim
        $ cat >../victim/.git/hooks/post-receive <<\EOF
            echo "post receive was here at $(date)"
        ) >>../STAMP
        $ chmod +x ../victim/.git/hooks/post-receive
        $ git push ../victim master:foo

The last "push" does not transfer any object (and obviously does not
satisfy your "at least 1 commit" requirement), but it does update
the STAMP file.  This is because it updates a ref and that is what
post-receive wants to react to, even if there is no new objects
placed in the receiving repository.

So an updated suggestion for the text would be:

     This hook is invoked by 'git-receive-pack' on the remote repository,
     which happens when a 'git push' is done on a local repository.

Oh, wait.  That is what we already have ;-).

Having said all that, there is one case that running 'git push' does
*NOT* cause 'receive-pack' to be invoked at the other end, and in
that scenario, obviously the hook cannot be run, simply because the
command that would run the hook is not run in the first place.

After the above sequence against the "victim" test repository, you
could try:

        $ git push ../victim master:foo
	Everything up-to-date

and observe that the STAMP file is not updated.

What is happening is that "git push" notices that there is nothing
gained by invoking receive-pack on the other side, because the
branch 'foo' already points at the commit at the tip of our

So it might technically be an improvement to update the text to
mention that 'git push' does not necessarily always lead to
invocation of receive-pack, something like:

     This hook is invoked by 'git-receive-pack' on the remote
     repository, which may happen when a 'git push' is done on a
     local repository.

but then that introduces the need to make the reader understand what
"may happen" is trying to say, iow, when does a user 'push' and it
does not trigger receive-pack?

But I do not think teaching that (i.e. when does receive-pack run?)
is the job of this paragraph, whose primary objective is to teach
about this hook that is run when receive-pack is run.  So...

  reply	other threads:[~2017-11-17  3:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16 22:40 Documentation of post-receive hook Christoph Michelbach
2017-11-17  1:41 ` Junio C Hamano
2017-11-17  3:24   ` Junio C Hamano [this message]
2017-11-19 17:31     ` Christoph Michelbach
2017-11-19 17:42       ` Robert P. J. Day
2017-11-19 18:55         ` Christoph Michelbach
2017-11-20  1:17       ` Junio C Hamano
2017-11-21 23:44         ` Christoph Michelbach
2017-11-22  1:14           ` Junio C Hamano
2017-11-22 19:09             ` Christoph Michelbach
2017-11-24  2:10             ` Re*: " Junio C Hamano

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).