Re: [PATCH 1/4] Documentation: explain push.default option a bit more

Michael Haggerty [off-list ref] 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.

On 04/21/2012 06:08 AM, Junio C Hamano wrote:

Michael Haggerty[off-list ref]  writes:

quoted

"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.

That's what I suspected.

Given that the word "atomic", for technical people, has a strict meaning 
that is not met here, and for non-technical people probably only means 
"nuclear", I suggest that the word be avoided in this explanation.  Perhaps

     * `matching` - push all branches having the same name in both ends.
       This is for those who prepare all the branches into a publishable
       shape and push them out atomically, and suitable when pushing to a
       non-shared repository. [...]

could be changed to

     * `matching` - push all branches having the same name in both ends.
       This allows those who prepare all the branches into a publishable
       shape to push them out to a non-shared repository with a single

 >        command. [...]

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/