Re: [PATCH v2 00/25] Lockfile correctness and refactoring

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

This is a second attempt at renovating the lock file code.  Thanks to
Peff, Junio, Torsten, and Eric for their helpful reviews of v1.

v1 of this patch series [1] did some refactoring and then added a new
feature to the lock_file API: the ability to activate a new version of
a locked file while retaining the lock.

But the review of v1 turned up even more correctness issues in the
existing implementation of lock files.  So this v2 dials back the
scope of the changes (it omits the new feature) but does more work to
fix problems with the current lock file implementation.

The main theme of this patch series is to better define the state
diagram for lock_file objects and to fix code that left them in
incorrect, indeterminate, or unexpected states.  There are also a few
patches that convert several functions to use strbufs instead of
limiting pathnames to a maximum length.

Looks OK to me, modulo the few comments I sent.

I still think resolve_symref should probably not be "best-effort", but
that can come later on top.

-Peff