Re: [PATCH 3/5] verify_lock(): report errors via a strbuf

Michael Haggerty [off-list ref] writes:

Instead of writing error messages directly to stderr, write them to a
"strbuf *err". In lock_ref_sha1_basic(), arrange for these errors to
be returned to its caller.

I had to scratch my head and view long outside the context before
realizing that the caller lock_ref_sha1_basic() already arranges
with its caller that errors from it are passed via the strbuf, and
this change is just turning verify_lock(), a callee from it, follows
that already established pattern.

Looks sensible, but the last sentence was misleading at least to me.

	The caller, lock_ref_sha1_basic(), uses this error reporting
	convention with all the other callees, and reports its error
        this way to its callers.

perhaps?

On 05/27/2015 09:48 PM, Junio C Hamano wrote:

Michael Haggerty [off-list ref] writes:

quoted

Instead of writing error messages directly to stderr, write them to a
"strbuf *err". In lock_ref_sha1_basic(), arrange for these errors to
be returned to its caller.

I had to scratch my head and view long outside the context before
realizing that the caller lock_ref_sha1_basic() already arranges
with its caller that errors from it are passed via the strbuf, and
this change is just turning verify_lock(), a callee from it, follows
that already established pattern.

Looks sensible, but the last sentence was misleading at least to me.

	The caller, lock_ref_sha1_basic(), uses this error reporting
	convention with all the other callees, and reports its error
        this way to its callers.

perhaps?

+1

Thanks for clarifying this sentence.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu