On Wednesday, March 7, 2007 at 12:09:04 (-0500) Shawn O. Pearce writes: >Bill Lear <rael@xxxxxxxxxx> wrote: >> On Wednesday, March 7, 2007 at 10:29:29 (-0600) Bill Lear writes: >> >... >> >whether it might be better to call the update hook after everything >> >had actually been written, including the log file. >> >> I dug into the code: in receive-pack.c, the command 'update(struct >> command *cmd)', calls write_ref_sha1() after run_update_hook() >> and does not check the return code of write_ref_sha1(). > >Please see the patch I just posted (and CC'd you on). We should >have caught the return error of write_ref_sha1, the patch now >does that. :) Ok, thank you for fixing this. I guess the call run_update_hook() should not in fact come after the write_ref_sha1() block, and just before the 'return 0' line, because you don't want to run the write_ref_sha1() at all if the update hook complains. >You probably want to use the post-update hook to send email. >This hook will always run if it exists and is executable, but it >won't be given a ref that failed to be updated. > >Of course an unfortunate downside to the post-update hook is it >does not receive the old SHA-1 of the ref; it just gets the ref name. Hmm, I agree that this sounds like the better place, logically speaking, for the email report to be generated, but unfortunate since I'm lame with git, so writing a post-update hook from scratch will probably be beyond my abilities, but since I just watched "Touching the Void" last night, I might be inspired to brave it. Since it just gets the ref name, would one (of sufficient skill) be able to reconstruct the same sort of report that the "pre" update hook does? That is, from the ref name can I get the old SHA-1? If I try to write this, what I think I would like to do is just call the existing update hook from the post-update hook, with the post update hook figuring out the proper arguments to pass along. Also, I do notice in refs.c:create_symref() that it does not check the return code of log_ref_write(). I don't know if that is done explicitly or not ... Bill - 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