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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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