git-commit-vandalism/refs
Jeff King 83a3069a38 lockfile: do not rollback lock on failed close
Since the lockfile code is based on the tempfile code, it
has some of the same problems, including that close_lock_file()
erases the tempfile's filename buf, making it hard for the
caller to write a good error message.

In practice this comes up less for lockfiles than for
straight tempfiles, since we usually just report the
refname. But there is at least one buggy case in
write_ref_to_lockfile(). Besides, given the coupling between
the lockfile and tempfile modules, it's less confusing if
their close() functions have the same semantics.

Just as the previous commit did for close_tempfile(), let's
teach close_lock_file() and its wrapper close_ref() not to
rollback on error. And just as before, we'll give them new
"gently" names to catch any new callers that are added.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-06 17:19:53 +09:00
..
files-backend.c lockfile: do not rollback lock on failed close 2017-09-06 17:19:53 +09:00
iterator.c prefix_ref_iterator: don't trim too much 2017-05-23 14:29:52 +09:00
packed-backend.c lockfile: do not rollback lock on failed close 2017-09-06 17:19:53 +09:00
packed-backend.h packed_refs_unlock(), packed_refs_is_locked(): new functions 2017-06-23 13:27:33 -07:00
ref-cache.c *.[ch] refactoring: make use of the FREE_AND_NULL() macro 2017-06-16 12:44:09 -07:00
ref-cache.h create_ref_entry(): remove check_name option 2017-05-23 14:29:56 +09:00
refs-internal.h Merge branch 'mh/ref-lock-entry' 2017-08-26 22:55:09 -07:00