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> ..." where <ref> is a ref name (which cannot contain spaces, even though some people seem to forget that rule) and <depth> is the number of times it has been locked already. <depth> of 0 is the current ".lock" file. So the first lock taken out by receive-pack would be setting: GIT_INHERITED_LOCKS="refs/heads/master 0" and another lock on the same ref by a subprocess would then update it to: GIT_INHERITED_LOCKS="refs/heads/master 1" etc... </hand-waving> -- 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
