Brian Vandenberg <phantall@xxxxxxxxx> writes:
> From: Junio C Hamano <junkio@xxxxxxx>
> Date: 2006-10-08 15:00:32
> Petr Baudis <pasky@xxxxxxx> writes:
>
>>> Someone raised a concern that the update and post-update hooks are not
>>> invoked at fetch time in the similar way as they are invoked at push
>>> time, and the idea sort of makes sense. But this patch goes further - it
>>> makes Git invoke those hooks each time a ref is updated in a repository
>>> using the git-update-ref command, which I believe makes a lot of sense as
>>> well - the behaviour is consistent with the current pushing behaviour
>>> and you suddenly finally get a hook where you can properly notify even
>>> about fast-forwards etc.
>
>>In principle I do not have problem with this approach per-se,
>>but I wonder if we were to do this we might want to make
>>receive-pack.c::update() and cmd_update_ref() call the same
>>underlying function, and make that underlying function implement
>>this "ask the hook if updating is ok" dance. It might even make
>>sense to have update-ref honor deny_non_fast_forwards for that
>>matter (I am mildly doubtful of this last point, though).
I am ultra-doubtful at this point ;-)
For one thing, update-ref is not a tool that is exclusive to
receiving object transfer aka receive-pack, so it makes no sense for
it to pay attention to post-update.
Also it is a low-level plumbing; the policy issues should come at a
level higher than that. I.e. Porcelain scripts implemented using
them as building blocks should be the ones that you do your policy,
e.g.
if whatever logic you want to use in your policy says OK
then
git update-ref ...args...
else
echo >&2 "My policy does not like your arguments"
exit 1
fi
--
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