From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Tue, 04 Dec 2007 02:12:05 GMT
Subject: Re: [PATCH v4] Allow update hooks to update refs on their own.
Message-ID: <Pine.LNX.4.64.0712040211270.27959@racer.site>
In-Reply-To: <20071204015108.GV14735@spearce.org>

Hi,

On Mon, 3 Dec 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 2 Dec 2007, Shawn O. Pearce wrote:
> > 
> > > Steven Grimm <koreth@midwinter.com> 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