Hi, On Mon, 3 Dec 2007, Shawn O. Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > On Mon, 3 Dec 2007, Shawn O. Pearce wrote: > > > 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>? > > Sure. :-) > > I was also hand-waving. Hoping someone else would fill in the > magic details. > > Actually <n> wouldn't be so bad. We could do something like: > > GIT_INHERITED_LOCKS="<ref> <depth> <ref> <depth> ..." I am somewhat wary of using environment variables in that context, since the variables could leak to subprocesses, or (even worse), they could be set inadvertently by the user or other scripts. 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
