Subject: Re: [PATCH v7 09/38] lock_file(): always initialize and register lock_file object

From: Michael Haggerty <[email-masked]>
Date: Wed, 01 Oct 2014 13:38:50 +0200

On 10/01/2014 01:27 PM, René Scharfe wrote:
> Am 01.10.2014 um 12:28 schrieb Michael Haggerty:
>> The purpose of this patch is to make the state diagram for lock_file
>> objects simpler and deterministic.
>>
>> If locking fails, lock_file() sometimes leaves the lock_file object
>> partly initialized, but sometimes not. It sometimes registers the
>> object in lock_file_list, but sometimes not. This makes the state
>> diagram for lock_file objects effectively indeterministic and hard to
>> reason about. A future patch will also change the filename field into
>> a strbuf, which needs more involved initialization, so it will become
>> even more important that the state of a lock_file object is
>> well-defined after a failed attempt to lock.
>>
>> The ambiguity doesn't currently have any ill effects, because
>> lock_file objects cannot be removed from the lock_file_list anyway.
>> But to make it easier to document and reason about the code, make this
>> behavior inconsistent: *always* initialize the lock_file object and
> 
> s/incon/con/, certainly?

Yes, thanks.

Junio, if another reroll is not necessary, would you mind fixing this
when applying?

Michael

-- 
Michael Haggerty
[email-masked]