Callers outside of refs.c use either lock_ref_sha1() or 
lock_any_ref_for_update() to lock a ref during an update.

Two of these places we do not immediately check the lock for failure
making reading the code harder.

One place we do some unrelated string manipulation fucntions before we
check for failure and the other place we rely on that write_ref_sha1()
will check the lock for failure and return an error.

These two patches updates these two places so that we immediately check the
lock for failure and act on it.
It does not change any functionality or logic but makes the code easier to
read by being more consistent.

Ronnie Sahlberg (2):
  sequencer.c: check for lock failure and bail early in fast_forward_to
  commit.c: check for lock error and return early

 builtin/commit.c | 8 ++++----
 sequencer.c      | 7 +++++++
 2 files changed, 11 insertions(+), 4 deletions(-)


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to