Re: [RFC] fetch: update refs in a single transaction

Jeff King [off-list ref] writes:

I suspect the surgery needed for the ref-transaction code to allow
non-atomic updates would be pretty big, though. It involves checking
every error case to make sure it is safe to continue rather than
aborting (and munging data structures to mark particular refs as
"failed, don't do anything further for this one").

So I dunno. All of my analysis assumes the breakdown of user
expectations I gave above is a reasonable one. There may be others. But
it seems like the behavior created by just this patch would be very hard
to explain, and subject to change based on implementation details.

Oh, I should have read your analysis before reacting to the original
message myself ;-)

Yes, current callers of ref-transaction code may have some logic to
decide that it is not even worth telling a proposed change to the
ref API (e.g. non-fast-forward) but that does feel like an
unnecessary implementation detail, and a true "partial transaction"
needs cooperation by the ref-transaction layer.

And when it is done, we do not have to explain anything to the user
beyond what we already do.  The "--atomic" option will make it
all-or-none, and without it, changes to each ref may or may not fail
individually with its own reason, without correlation to the outcome
of the changes to any other refs.  And use of single or multiple
transactions just becomes an implementation detail of non-atomic
updates.