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). Was this rejected? I'm tweaking the configuration on our master repo; among other things: I've enabled reflog and disabled altering history or deleting branches through receive-pack, instead requiring that someone make history alterations directly (using update-ref). update-ref can optionally accept a comment explaining why the history needed to be altered, but we would prefer to make it mandatory. Hooks seem like a natural place to do that, but after running update-ref under strace/truss & looking through builtin/update-ref.c, it looks as though it doesn't make use of hooks. -Brian -- 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