On Tue, Jun 09, 2015 at 12:50:13PM +0200, Michael Haggerty wrote:
> 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.
Thanks for the explanation. I agree it probably doesn't matter much
either way.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
