Junio C Hamano <junkio@xxxxxxx> wrote:
> 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 ;-).
Agreed.
--
Shawn.
-
: 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