> 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 in run_pre_push_hook() that omits such
> refs from the hook input looks just *wrong*.  On the other hand, I
> do not offhand think of a valid reason for the push codepath (with
> or without the pre-push hook) to send "this ref has to point at that
> object" when we know the ref is already pointing at that object, so
> I am not sure if your claim (i.e. "when ... was already pushed
> previously") is true for a correctly built receiving side of Git.

No I totally understand that the pre-receive is the ideal place to do
it, and I can see that it's not feasible to rework how pre-push was
designed if it was specifically made not to handle this kind of
situation. In a perfect world I would just remove/modify the
post-receive hook causing the undesirable behavior, but I work within
the restrictions of my environment. 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.

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/).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to