Am 12.07.2013 19:40, schrieb Junio C Hamano: > Johannes Sixt <j...@kdbg.org> writes: > >> Am 12.07.2013 00:14, schrieb Junio C Hamano: >>> Johannes Sixt <j...@kdbg.org> writes: >>> >>>> Again: Why not just define +refspec as the way to achieve this check? >>> >>> What justification do we have to break existing people's >>> configuration that says something like: >>> >>> [remote "ko"] >>> url = kernel.org:/pub/scm/git/git.git >>> push = master >>> push = next >>> push = +pu >>> push = maint >>> >>> by adding a _new_ requirement they may not be able to satisify? >>> Notice that the above is a typical "push only" publishing point, >>> where you do not need any remote tracking branches. >> >> Why would it break? When you do not specify --lockref, there is no >> change whatsoever. > > I thought your suggestion "Why not just define +pu as the way to > achieve _THIS_ check?" was to make +pu to mean > > git push ko --lockref pu > > which would mean "check refs/remotes/ko/pu and make sure the remote > side still is at that commit". > > If that is not what you meant, please clarify what _THIS_ is.
We have three independent options that the user can choose in any combination: o --force given or not; o --lockref semantics enabled or not; o refspec with or without +; and these two orthogonal preconditions of the push o push is fast-forward or it is not ("ff", "noff"); o the branch at the remote is at the expected rev or it is not ("match", "mismatch"). Here is a table with the expected outcome. "ok" means that the push is allowed(*), "fail" means that the push is denied. (Four more lines with --force are omitted because they have "ok" in all spots.) ff noff ff noff match match mismatch mismatch --lockref +refspec ok ok denied denied --lockref refspec ok denied denied denied +refspec ok ok ok ok refspec ok denied ok denied Notice that without --lockref semantics enabled, +refspec and refspec keep the current behavior. (*) As we are talking only about the client-side of the push here, I'm saying "allowed" instead of "succeeds" because the server can have additional restrictions that can make the push fail. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html