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(-) -- 1.9.1.503.ge4c3920.dirty -- To unsubscribe from this list: 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