Patrick Steinhardt <ps@xxxxxx> writes: > The git-update-ref(1) command can only handle queueing transactions > right now via its "--stdin" parameter, but there is no way for users to > handle the transaction itself in a more explicit way. E.g. in a > replicated scenario, one may imagine a coordinator that spawns > git-update-ref(1) for multiple repositories and only if all agree that > an update is possible will the coordinator send a commit. Such a > transactional session could look like > > > start > < start: ok > > update refs/heads/master $OLD $NEW > > prepare > < prepare: ok > # All nodes have returned "ok" > > commit > < commit: ok > > or > > > start > < start: ok > > create refs/heads/master $OLD $NEW > > prepare > < fatal: cannot lock ref 'refs/heads/master': reference already exists > # On all other nodes: > > abort > < abort: ok > > In order to allow for such transactional sessions, this commit > introduces four new commands for git-update-ref(1), which matches those > we have internally already with the exception of "start": > > - start: start a new transaction > > - prepare: prepare the transaction, that is try to lock all > references and verify their current value matches the > expected one > > - commit: explicitly commit a session, that is update references to > match their new expected state > > - abort: abort a session and roll back all changes OK, this is a fun stuff, and explains why we wanted to do [7/9].
