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

Michael Haggerty <mhagger@alum.mit.edu> writes:

Actually, I'd feel worried if this were on the receive-pack side, as it is entirely valid that two or more people make uncoordinated push into a single meeting point, but much less for something like "fetch". I do not see a valid reason why somebody cannot avoid fetching into the same repository in a racy way.

I agree that transaction is a wrong way to look at this. I view "We know packed refs is a lot more efficient if written once" as in the same category as "We know we will register many new objects with this operation, so instead of creating them into separate loose object files, declare that the object store is 'plugged' and send them into a single new packfile" (aka "bulk checkin"). Both are uninterested in all-or-none execution, but merely want to declare a boundary between a group of operations to help Git optimize them.

I think it would make sense, but I suspect you would want to make it clear that the function is best-effort-bulk somewhere in its name (e.g. delete-refs-if-able or something) and make it not to automatically fail the surrounding transaction if any. That way an application could do things like this:

    transaction-begin;
      create-ref;
      update-ref;
      ...
      delete-refs-if-able;
      if trying to be as atomic as possible
      then
	if previous delete-refs-if-able found undeletable refs
        then
          transaction-abort;
	fi
      fi
    transaction-commit;

Of course, supplying delete-refs that is not best-effort separately would make it even easier to code the above (the last if/then/fi will become unnecessary).