Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> "Atomic" implies that either the whole push succeeds or the whole push
> fails, and that readers will never see part of the push.
Oh, I didn't mean "atomic" in that strict sense. After all this was a
description at the workflow level--what the human user perceives.
When pushing into the repository you control and nobody else messes
with, you may want update both 'master' and 'devel' with the same "git
push", and that is quite different from current/upstream/simple
model. That is all I meant.
At the mechanical level, we:
- read all the refs we are going to update and remember their values;
- send and store all the necessary objects; and
- for each ref:
- lock it;
- read it;
- is it different from what we read originally?
- if so, do not update it and remember the fact that we saw a failure;
- otherwise update it;
- unlock it;
so it won't be the kind of "atomic" in the "if 'master' will fail to
update due to non-fast-forward, not just 'master' but also 'devel' is
not updated" sense.
Also, if you happen to observe 'devel' and 'master' when a push is in
progress, you may get lucky and see the new value of 'devel' and old
value of 'master'. In that sense, too, it is not "atomic", either.
In the workflow where 'matching' is appropriate, the former won't be an
issue. The latter might be, but it is not like you push objects for
devel, update devel, then push objects for master and the update master,
so the window of race is very small.
--
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