Chris O'Kelly ch...@mapcreative.com.au 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
Chris O'Kelly ch...@mapcreative.com.au writes:
A brief background of my use case:
I am wanting to write a pre-push hook to prevent tags being pushed to
our production servers. The production servers in our case are --bare
endpoints, and when we push a tag at them, they always checkout the
Chris O'Kelly ch...@mapcreative.com.au writes:
[administrivia: people read from top to bottom; please do not top
post]
On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano gits...@pobox.com wrote:
Chris O'Kelly ch...@mapcreative.com.au writes:
A brief background of my use case:
I am wanting to
I do not offhand know (I am on a bus with terrible connection so I
won't bother checking the source now) if we send this ref has to
point at that object even for STATUS_UPTODATE cases, to cause your
remote to trigger the receive hook in the frist place, but if that
is the case, then the code
Unfortunately in this case we don't have control over the hooks at the
receiving end - we want to prevent tags from being pushed by all users
to these repo's.
On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano gits...@pobox.com wrote:
Chris O'Kelly ch...@mapcreative.com.au writes:
A brief
Hello,
Just a brief note about a feature I would find incredibly useful, were
it available.
A brief background of my use case:
I am wanting to write a pre-push hook to prevent tags being pushed to
our production servers. The production servers in our case are --bare
endpoints, and when we push a
6 matches
Mail list logo
