Jeff King <peff@xxxxxxxx> 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.
