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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 04/20/2012 11:28 PM, Junio C Hamano wrote:
> [...]
> Perhaps make this part a separate paragraph so that it stands out a bit
> more, like this,
>
>      * `current` - push the current branch to a branch of the same name.
>      +
>      The `current` and `upstream` modes are for those who want to
>      push out a single branch after finishing work, even when the other
>      branches are not yet ready to be pushed out.
>
> and update the description for `matching` to explain why it is suited
> for what we claim that it is suited for, like so:
>
>      * `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. It is not appropriate to use when pushing into
>        a repository shared by multiple users, since locally stalled branches
>        will attempt a non-fast forward push if other users updated the branch
>        remotely.
>      +
>      This is the default.

"Atomic" implies that either the whole push succeeds or the whole push 
fails, and that readers will never see part of the push.  Is full 
atomicity really guaranteed?  Does the guarantee depend on the 
repository being non-shared?  What if the repo has one writer but 
multiple readers?

I have trouble answering questions like these because I haven't figured 
out the big picture of git's locking model.  In the code, all I have 
seen so far is fine-grained locks that only block writers (though the 
fast-index GSoC proposal includes a plan to introduce a lock on the 
index that blocks readers).  Is git's locking model documented somewhere?

Michael

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