From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Tue, 09 Jun 2015 10:50:13 GMT
Subject: Re: [PATCH 07/13] prune_remote(): use delete_refs()
Message-ID: <5576C4E5.4080107@alum.mit.edu>
In-Reply-To: <20150608171202.GB6863@peff.net>

On 06/08/2015 07:12 PM, Jeff King wrote:
> On Mon, Jun 08, 2015 at 09:57:04AM -0700, Stefan Beller wrote:
> 
>> On Mon, Jun 8, 2015 at 4:45 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> 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