On Tue, Jul 2, 2013 at 10:57 PM, Junio C Hamano <gits...@pobox.com> 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?
$ 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
$ 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
Johan Herland, <jo...@herland.net>
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