Re: Feature Request: provide cmdline args to git hooks

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2015, 18:18 UTC
Message-ID: <xmqqk2xdl0fj.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAM-hpQf2hzjufYxmc2uGUhoqn3JVnwwcoOPOnya4MJbCnjkg3A@mail.gmail.com>

"Chris O'Kelly" <chris@mapcreative.com.au> writes:

Show 8 quoted lines

> To reiterate and clarify I'm not saying the undesirable behavior
> is a built in part of git, just a feature of our hosting
> platform's Git deployment mechanisms, although if what you mean is
> that the post-receive hook on the receiving end shouldn't be
> getting passed pushed tag refs that the local git believed to be
> already up to date on the remote (as of most recent fetch), then
> yeah... that is weird because it seems to be the behavior in this
> case.

I just checked.

    $ rm -fr new && mkdir new && cd new
    $ git init src && git init --bare dst
    $ cd src
    $ echo "(date;cat) >pushlog" >.git/hooks/pre-push
    $ chmod +x .git/hooks/pre-push
    $ git commit -m 'initial' --allow-empty
    $ git tag -m 'initial' initial

Push only the branch:

    $ GIT_TRACE_PACKET=1 git push ../dst master 2>&1 | grep 'push>'
    11:07:26.... packet: push> 0000... 66ba... refs/heads/master\0report-st...
    11:07:26.... packet: push> 0000
    $ cat pushlog
    Wed Apr 15 11:07:26 PDT 2015
    refs/heads/master 66ba... refs/heads/master 0000...

In the packet trace, we can see that we told the remote to update 'master', and the pre-push logger also records the same.

Then push with --follow-tags:

    $ GIT_TRACE_PACKET=1 git push --follow-tags ../dst master 2>&1 | grep 'push>'
    11:09:53.... packet: push> 0000... 30fa... refs/tags/initial\0report-st...
    11:09:53.... packet: push> 0000
    $ cat pushlog
    Wed Apr 15 11:09:53 PDT 2015
    refs/tags/initial 30fa... refs/tags/initial 0000...

We can see that we told the remote to store the tag, which matches what the pre-push saw.

And then an empty push:

    $ GIT_TRACE_PACKET=1 git push --follow-tags ../dst master 2>&1 | grep 'push>'
    11:11:23.... packet: push> 0000
    $ cat pushlog
    Wed Apr 15 11:11:23 PDT 2015

We tell them to do nothing, and pre-push saw nothing.

For a good measure, let's advance the branch and push it out:

    $ git commit --allow-empty -m second
    $ GIT_TRACE_PACKET=1 git push --follow-tags ../dst master 2>&1 | grep 'push>'
    11:13:43.... packet: push> 66ba... e711... refs/heads/master\0report-st...
    11:13:43.... packet: push> 0000
    $ cat pushlog
    Wed Apr 15 11:13:43 PDT 2015
    refs/heads/master e711... refs/heads/master 66ba...

We notice that the tag is up to date and do not tell them to do anything to it, and pre-push did not see the tag either.

As far as I can see so far, the behaviour of the underlying push (i.e. what we decide to tell the remote to update) is sensible, and what pre-push is told we are doing by the command is consistent with what is really pushed.

So....

Show 5 quoted lines

> Anyway it sounds like the answer here is that it really isn't a
> feasible task in a client side hook, and we should stick with the
> current solution of "Don't use the GUI to push to Live" for now, which
> is fine; I should probably stop trying to script around every single
> problem anyway (https://xkcd.com/1319/).

It appears that your "GUI" is a broken implementation of Git, that tells the other side to update what it did not even send, and that is what is causing the trouble, perhaps?