Re: Why is "git fetch --prune" so much slower than "git remote prune"?

From: Jeff King <peff@peff.net>
Date: Mar 19, 2015, 17:14 UTC
Message-ID: <20150319171416.GB6386@peff.net>
In-Reply-To: <550AE1E4.7020407@alum.mit.edu>

On Thu, Mar 19, 2015 at 03:49:08PM +0100, Michael Haggerty wrote:

Show 11 quoted lines

> For pruning, we can't use a ref_transaction as it is currently
> implemented because it would fail if any of the reference deletions
> failed. But in this case I think if any deletions fail, we would prefer
> to emit a warning but keep going.
>
> I'm trying to decide whether to have a separate function in the refs API
> to "delete as many of the following refs as possible", or whether to add
> a flag to ref_transaction_update() that says "try this update, but don't
> fail the transaction if it fails". The latter would probably be more
> work because we would need to invent a way to return multiple error
> messages from a single transaction.

Hmm, yeah. That is sort of antithetical to the original purpose of ref transactions (which was atomicity). Given the way it is implemented now, I don't think it would be too big a deal to keep a per-ref status (one per "struct ref_upate"). But I would worry in the long run that it makes things much harder on proposed ref backends, which otherwise can consider a transaction an atomic unit.

OTOH, I do not think there is an abstracted way to do this _without_ the ref backend knowing about it. You cannot just do a series of transactions; that defeats the purpose. It is a bit of a layering violation that builtin/remote.c (which does this optimization already) calls repack_without_refs directly.

-Peff