Re: [PATCH 07/13] prune_remote(): use delete_refs()

On 06/08/2015 07:12 PM, Jeff King wrote:

On Mon, Jun 08, 2015 at 09:57:04AM -0700, Stefan Beller wrote:

quoted

On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty [off-list ref] wrote:

quoted

This will result in errors being emitted for references that can't be
deleted, but that is a good thing.

This sounds a bit like hand-waving to me. "Trust me, I'm an engineer!".

I think the argument is "we failed to do that the user asked for, but
never reported the reason why".

But I don't see how that is the case. We already complain if
repack_without_refs fail, and AFAICT the original call to delete_ref()
would emit an error, as well.

The old and new code report errors that come from repack_without_refs()
the same way. The difference is how they report errors within delete_ref().

The old code only allowed delete_ref() to emit its error.

The new code (in delete_refs()) allows delete_ref() to emit its error,
but then follows it up with

    error(_("could not remove reference %s"), refname)

The "could not remove reference" error originally came from a similar
message in remove_branches() (from builtin/remote.c).

I *think* this is an improvement, because the error from delete_ref()
(which usually comes from ref_transaction_commit()) can be pretty
low-level, like

    Cannot lock ref '%s': unable to resolve reference %s: %s

where the last "%s" is the original strerror.

I would be happy to change the behavior if somebody has a concrete wish.
At the same time I don't think we need to sweat the details too much,
because these errors should only ever be seen in the case of a broken
repository or a race between two processes; i.e., only in pretty rare
and anomalous situations.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu