> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html