diff options
author | Michael Haggerty <mhagger@alum.mit.edu> | 2014-10-01 10:28:13 (GMT) |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-10-01 20:43:50 (GMT) |
commit | 04e57d4d32541bc5dba553a31f09aa2ee456bdad (patch) | |
tree | 7303402f8634a15e94c3e20461290036bdc1d4d4 /Documentation/git-sh-i18n.txt | |
parent | ebb8e380e98e83f32c1cc04200d3749ab4c0b90a (diff) | |
download | git-04e57d4d32541bc5dba553a31f09aa2ee456bdad.zip git-04e57d4d32541bc5dba553a31f09aa2ee456bdad.tar.gz git-04e57d4d32541bc5dba553a31f09aa2ee456bdad.tar.bz2 |
lock_file(): always initialize and register lock_file object
The purpose of this change is to make the state diagram for
lock_file objects simpler and deterministic.
If locking fails, lock_file() sometimes leaves the lock_file object
partly initialized, but sometimes not. It sometimes registers the
object in lock_file_list, but sometimes not. This makes the state
diagram for lock_file objects effectively indeterministic and hard
to reason about. A future patch will also change the filename field
into a strbuf, which needs more involved initialization, so it will
become even more important that the state of a lock_file object is
well-defined after a failed attempt to lock.
The ambiguity doesn't currently have any ill effects, because
lock_file objects cannot be removed from the lock_file_list anyway.
But to make it easier to document and reason about the code, make
this behavior consistent: *always* initialize the lock_file object
and *always* register it in lock_file_list the first time it is
used, regardless of whether an error occurs.
While we're at it, make sure that all of the lock_file fields are
initialized to values appropriate for an unlocked object; the caller
is only responsible for making sure that on_list is set to zero before
the first time it is used.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/git-sh-i18n.txt')
0 files changed, 0 insertions, 0 deletions