Bill Lear <rael@xxxxxxxxxx> wrote:
> 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.
Exactly. :-)
> >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.
If you have a reflog enabled you can use name@{1}..name to generate
the list, but this is subject to a race condition as the ref could
be updated by someone else before you get to look at it to generate
the output.
I'm actually working on a patch right now to create a new hook
(hooks/post-receive ?) that takes the 3 arg form like hooks/update
does, avoiding the race condition entirely.
--
Shawn.
-
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