On Sun, Sep 25, 2011 at 3:18 PM, Pang Yan Han <pangyanhan@xxxxxxxxx> wrote:
> On Sun, Sep 25, 2011 at 01:28:31PM +0530, Sitaram Chamarty wrote:
[snip]
>> It doesn't make sense to disable only the update hook. And although I
>> did not come right out and say it, it is the post-update that I care
>> about. If that still runs, my "issue" still exists.
> Um I'm rather new to Git and the reason why I didn't reply this initially was
> because I didn't know what to reply. Sorry but you sound rather aggressive and
> I was really taken aback by this.
Sorry if I sounded aggressive; I was going to brevity, and levity suffered :-)
[snip lots of stuff about new approach]
> What do you think of this approach (if it's even correct)?
I'm sorry again but it's been almost 2 decades since I did any serious
C and I've never dug into git internals, so I can't tell you if you're
even on the right track. You should wait for one of the other folks
you cc-d to weigh in with their opinions.
Personally, anytime someone says "disable the update hook" I get very
worried -- I've got a heck of a lot invested in update hooks ;-)
I wasn't even *asking* about disabling that; I was asking about
*post*-update, which you didn't even address in your code.
>From a philosophical point of view, update and pre-receive *check*
things to make sure everything is OK. IMO they should be allowed to
run even if the ref being deleted doesn't exist -- that could well be
an error condition that the guy who owns the repo wants to trap and
alert himself to in some special way. I would *not* like them
disabled.
Post-{update,receive} are for *after* a successful push. My
suggestion would be to make sure the inputs supplied to those hooks
(via STDIN for post-receive, and as arguments in case of post-update)
reflect this -- only successfully updated refs are sent in as args.
This might mean that in the case of 'git push origin
:refs/heads/non-existent-ref' the post-receive hook would run but
STDIN would be empty, and post-update would run but have no arguments.
That is, IMO, the correct way to deal with this.
--
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