Re: [PATCH v5 08/35] lock_file(): always add lock_file object to lock_file_list

2014-09-18 Thread Michael Haggerty
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 char *path,

Re: [PATCH v5 08/35] lock_file(): always add lock_file object to lock_file_list

2014-09-17 Thread Michael Haggerty
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 use

Re: [PATCH v5 08/35] lock_file(): always add lock_file object to lock_file_list

2014-09-17 Thread Torsten Bögershausen
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

[PATCH v5 08/35] lock_file(): always add lock_file object to lock_file_list

2014-09-16 Thread Michael Haggerty
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