_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.

When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file.  With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.

However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break.  This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.

Signed-off-by: Junio C Hamano <junkio@cox.net>

1 files changed, 2 insertions, 2 deletions

diff --git a/builtin-update-index.c b/builtin-update-index.c
index 71cef633c..84993d7c5 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -495,7 +495,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
 	/* We can't free this memory, it becomes part of a linked list parsed atexit() */
 	lock_file = xcalloc(1, sizeof(struct lock_file));
 
-	newfd = hold_lock_file_for_update(lock_file, get_index_file(), 0);
+	newfd = hold_locked_index(lock_file, 0);
 	if (newfd < 0)
 		lock_error = errno;
 
@@ -661,7 +661,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
 			    get_index_file(), strerror(lock_error));
 		}
 		if (write_cache(newfd, active_cache, active_nr) ||
-		    close(newfd) || commit_lock_file(lock_file))
+		    close(newfd) || commit_locked_index(lock_file))
 			die("Unable to write new index file");
 	}