"Chris O'Kelly" <chris@xxxxxxxxxxxxxxxxxx> writes:
> 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....
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html