On Tue, Jul 2, 2013 at 10:57 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: [...] > (2) Add --compare-and-swap=dst:expect parameters, e.g. > > $ git push --cas=master:deadbabecafe --cas=next:cafebabe ":" > > This removes the "reservation" I expressed against (1) above > (i.e. we are doing a "matching" push in this example, but we > will fail if 'master' and 'next' are not pointing at the > expected objects). I still think this is too long/verbose for the average user to remember, and type out. Also, I don't like the name, as it is too 'technical', and describes the nature of the implementation (i.e. the "how") rather than the purpose of using it (i.e. the "why" or "what"). > (3) Add a mechanism to call a custom validation script after "git > push" reads the list of <current object name, refname> tuples, > but before responding with the proposed update. The script > would be fed a list of <current object name, new object > name, refname> tuples (i.e. what the sender _would_ tell the > receiving end if there weren't this mechanism), and can tell > "git push" to fail with its exit status. > > This would be the most flexible in that the validation does > not have to be limited to "the ref must be still pointing at > the object we expect" (aka compare-and-swap); the script could > implement other semantics (e.g. "the ref must be pointing at > the object or its ancestor"). With this, I guess --dry-run could be reformulated as a trivial validation script that always returns a non-zero exit code (although it should still cause 'push' to return zero). [...] > I am inclined to say, if we were to do this, we should do (2) among > the above three. > > But of course, others may have better ideas ;-). I assume that in most cases the expected value of the remote ref would equal the current value of the corresponding remote-tracking ref in the user's repo, so why not use that as the default expected value? E.g.: $ git config push.default simple $ git checkout -b foo -t origin/foo # prepare non-ff update $ git push --force-if-expected # the above validates foo @ origin != origin/foo before pushing And if the users expects a different value, (s)he can pass that to the same option: $ git push --force-if-expected=refs/original/foo my_remote HEAD:foo # the above fails if foo @ origin != refs/original/foo The option name probably needs a little work, but as long as it properly communicates the user's _intent_ I'm fine with whatever we call it. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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