Steven Grimm <koreth@xxxxxxxxxxxxx> wrote: > This is useful in cases where a hook needs to modify an incoming commit > in some way, e.g., fixing whitespace errors, adding an annotation to > the commit message, noting the location of output from a profiling tool, > or committing to an svn repository using git-svn. ... > +/* Update hook exit code: hook has updated ref on its own */ > +#define EXIT_CODE_REF_UPDATED 100 Hmm. I would actually rather move the ref locking to before we run the update hook, so the ref is locked *while* the hook executes. If we ran a hook and it exited 0 then re-read the ref to see if the value differs from old_sha1; if it does then we can assume the update hook took care of the update. If the value is still old_sha1 then we know the hook didn't do the update and we need to do it for the hook. This probably requires exporting the name of the ref we currently have locked in an environment variable (and teach lockfile.c it) so we can effectively do recursive locking. That way the update hook can still use git-update-ref to change the ref safely. The advantage of this approach is the hook programmer doesn't need to implement their own locking scheme and we also don't make a special case exit code where there wasn't one before. -- 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
