On 09/18/2014 06:32 AM, Torsten Bögershausen wrote:
> On 09/16/2014 09:33 PM, Michael Haggerty wrote:
> []
>>
>> diff --git a/lockfile.c b/lockfile.c
>> index 983c3ec..00c972c 100644
>> --- a/lockfile.c
>> +++ b/lockfile.c
>> @@ -129,6 +129,22 @@ static int lock_file(struct lock_file *lk, const cha
On 09/16/2014 09:33 PM, Michael Haggerty wrote:
[]
>
> diff --git a/lockfile.c b/lockfile.c
> index 983c3ec..00c972c 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -129,6 +129,22 @@ static int lock_file(struct lock_file *lk, const char
> *path, int flags)
>*/
> static const size_t
On 09/16/2014 10:57 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> The ambiguity didn't have any ill effects, because lock_file objects
>> cannot be removed from the lock_file_list anyway. But it is
>> unnecessary to leave this behavior inconsistent.
>
> Nit: commit messages usually u
Michael Haggerty wrote:
> The ambiguity didn't have any ill effects, because lock_file objects
> cannot be removed from the lock_file_list anyway. But it is
> unnecessary to leave this behavior inconsistent.
Nit: commit messages usually use present tense for current behavior
(and imperative for
It used to be that if locking failed, lock_file() usually did not
register the lock_file object in lock_file_list but sometimes it did.
This confusion was compounded if lock_file() was called via
hold_lock_file_for_append(), which has its own failure modes.
The ambiguity didn't have any ill effect
5 matches
Mail list logo
