From d613576dfe7010b13157e63b2401d321074bbab8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20=C3=85gren?= Date: Thu, 5 Oct 2017 22:32:05 +0200 Subject: [PATCH] lockfile: fix documentation on `close_lock_file_gently()` MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit 83a3069a3 (lockfile: do not rollback lock on failed close, 2017-09-05) forgot to update the documentation by the function definition to reflect that the lock is not rolled back in case closing fails. Signed-off-by: Martin Ă…gren Signed-off-by: Junio C Hamano --- lockfile.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lockfile.h b/lockfile.h index 7c1c484d7c..f401c979f0 100644 --- a/lockfile.h +++ b/lockfile.h @@ -240,8 +240,8 @@ extern char *get_locked_file_path(struct lock_file *lk); * If the lockfile is still open, close it (and the file pointer if it * has been opened using `fdopen_lock_file()`) without renaming the * lockfile over the file being locked. Return 0 upon success. On - * failure to `close(2)`, return a negative value and roll back the - * lock file. Usually `commit_lock_file()`, `commit_lock_file_to()`, + * failure to `close(2)`, return a negative value (the lockfile is not + * rolled back). Usually `commit_lock_file()`, `commit_lock_file_to()`, * or `rollback_lock_file()` should eventually be called. */ static inline int close_lock_file_gently(struct lock_file *lk)