summaryrefslogtreecommitdiff
path: root/lockfile.c
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2014-07-14 10:29:58 -0700
committerJunio C Hamano <gitster@pobox.com>2014-07-14 13:05:37 -0700
commit93dcaea22674864f931be3fe6050671d335dc5b0 (patch)
tree766396abcc4aba5fa2ac49aec1ff5b5cd11bb7e3 /lockfile.c
parent3e52f70b1505956bf91cb7b107e526d1c67da0a6 (diff)
downloadgit-93dcaea22674864f931be3fe6050671d335dc5b0.tar.gz
lockfile: allow reopening a closed but still locked filejc/reopen-lock-file
In some code paths (e.g. giving "add -i" to prepare the contents to be committed interactively inside "commit -p") where a caller takes a lock, writes the new content, give chance for others to use it while still holding the lock, and then releases the lock when all is done. As an extension, allow the caller to re-update an already closed file while still holding the lock (i.e. not yet committed) by re-opening the file, to be followed by updating the contents and then by the usual close_lock_file() or commit_lock_file(). This is necessary if we want to add code to rebuild the cache-tree and write the resulting index out after "add -i" returns the control to "commit -p", for example. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'lockfile.c')
-rw-r--r--lockfile.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/lockfile.c b/lockfile.c
index b706614349..9c12ec5ca6 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -228,6 +228,16 @@ int close_lock_file(struct lock_file *lk)
return close(fd);
}
+int reopen_lock_file(struct lock_file *lk)
+{
+ if (0 <= lk->fd)
+ die(_("BUG: reopen a lockfile that is still open"));
+ if (!lk->filename[0])
+ die(_("BUG: reopen a lockfile that has been committed"));
+ lk->fd = open(lk->filename, O_WRONLY);
+ return lk->fd;
+}
+
int commit_lock_file(struct lock_file *lk)
{
char result_file[PATH_MAX];