Hi, On Mon, 3 Dec 2007, Shawn O. Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > On Sun, 2 Dec 2007, Shawn O. Pearce wrote: > > > > > 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. > > > > Would that not mean that you cannot use update-ref to update the ref, > > since that wants to use the same lock? > > You failed to quote the part of my email where I talked about how > we set an evironment variable to pass a hint to lockfile.c running > within the git-update-ref subprocess to instruct it to perform a > different style of locking, one that would work as a "recursive" > lock. > > Such a recursive lock could be useful for a whole lot more than just > the update hook. But it would at least allow the update hook to > use git-update-ref to safely change the ref, without receive-pack > losing its own lock on the ref. Indeed, I even failed to read it fully ;-) What do you propose, though? <filename>.lock.<n>? Ciao, Dscho - 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
