Junio C Hamano <junkio@xxxxxxx> writes:
> Looking at output from:
>
> $ git grep -A 3 hold_lock_file_for_update
>
> I wonder if it might be more consistent to do something like
> this instead. It removes more lines than it adds ;-).
>
> Most of the callers except the one in refs.c use the function to
> update the index file. Among the index writers, everybody
> except write-tree dies if they cannot open it for writing.
>
> diff --git a/refs.c b/refs.c
> index 28a9394..564f8a7 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -319,7 +319,7 @@ static struct ref_lock *lock_ref_sha1_ba
>
> if (safe_create_leading_directories(lock->ref_file))
> die("unable to create directory for %s", lock->ref_file);
> - lock->lock_fd = hold_lock_file_for_update(lock->lk, lock->ref_file);
> + lock->lock_fd = hold_lock_file_for_update(lock->lk, lock->ref_file, 0);
> if (lock->lock_fd < 0) {
> error("Couldn't open lock file %s: %s",
> lock->lk->filename, strerror(errno));
Looking at this part further, it seems that this one could
simply die when it fails -- after all it dies when leading
directories cannot be created, so dying upon failure of
hold_lock_file_for_update() would be consistent ;-).
Which makes write-tree the only odd-man-out.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html