On Thu, Mar 19, 2015 at 03:49:08PM +0100, Michael Haggerty wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html