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,
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
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
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
4 matches
Mail list logo