Re: [PATCH v2 17/25] commit_lock_file(): make committing an unlocked lockfile a NOP

From: Jeff King <peff@peff.net>
Date: Apr 7, 2014, 19:31 UTC
Message-ID: <20140407193131.GC19342@sigill.intra.peff.net>
In-Reply-To: <1396827247-28465-18-git-send-email-mhagger@alum.mit.edu>

On Mon, Apr 07, 2014 at 01:33:59AM +0200, Michael Haggerty wrote:

Show 16 quoted lines

> It was previously a bug to call commit_lock_file() with a lock_file
> object that was not active (an illegal access would happen within the
> function).  It was presumably never done, but this would be an easy
> programming error to overlook.  So guard the file-renaming code with
> an if statement to change committing an unlocked file into a NOP.
> 
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
> Alternatively, we could make it a fatal error (e.g., an assert() or
> if...die()) to call commit_lock_file() on an unlocked file, or omit a
> warning in this case.  But since it is so hard to test code related to
> locking failures, I have the feeling that such an error is most likely
> to occur in some error-handling path, maybe when some other lockfile
> acquisition has failed, and it would be better to let the code
> continue its attempted cleanup instead of dying.  But it would be easy
> to persuade me to change my opinion.

Yeah, I would have expected a die("BUG") here.

I think it is worth making it a fatal mistake and catching it. Rolling back an uninitialized lockfile is probably OK; we are canceling an operation that never started. But committing a lockfile that we didn't actually fill out could be a sign of a serious error, and we may be propagating a bogus success code. E.g., imagine that receive-pack claims to have written your ref, but actually commit_lock_file was a silent NOP. I'd much rather have it die loudly so we can track down the case.

-Peff