diff options
| author | Junio C Hamano <gitster@pobox.com> | 2017-07-06 11:36:35 -0700 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2017-07-06 15:43:37 -0700 |
| commit | f2f60a5935e3673e6df2a45b25c961587d9a2186 (patch) | |
| tree | bb233b5cde90ce1483d434f0acaca6d2e26e1b69 /send-pack.c | |
| parent | 50ff9ea4a0770c8b1bfe3f98f09728427c0c6cc7 (diff) | |
| download | git-jc/allow-lazy-cas.tar.gz | |
push: disable lazy --force-with-lease by defaultjc/allow-lazy-cas
"git push --force-with-lease=<branch>:<expect>" makes sure that
there is no unexpected changes to the branch at the remote while you
prepare a rewrite based on the old state of the branch. This
feature came with an experimental option that allows :<expect> part
to be omitted by using the tip of remote-tracking branch that
corresponds to the <branch>.
It turns out that some people use third-party tools that fetch from
remote and update the remote-tracking branches behind users' back,
defeating the safety that relies on the stability of the remote-tracking
branches. We have some warning text that was meant to sound scary
in our documentation, but nevertheless people seem to be bitten. See
https://public-inbox.org/git/1491617750.2149.10.camel@mattmccutchen.net/
for a recent example.
Let's disable the forms that rely on the stability of remote-tracking
branches by default, and allow users who _know_ their remote-tracking
branches are stable to enable it with a configuration variable.
This problem was predicted from the very beginning; see 28f5d176
(remote.c: add command line option parser for "--force-with-lease",
2013-07-08).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'send-pack.c')
| -rw-r--r-- | send-pack.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/send-pack.c b/send-pack.c index 11d6f3d983..94f0ad2b14 100644 --- a/send-pack.c +++ b/send-pack.c @@ -248,6 +248,7 @@ static int check_to_send_update(const struct ref *ref, const struct send_pack_ar case REF_STATUS_REJECT_FETCH_FIRST: case REF_STATUS_REJECT_NEEDS_FORCE: case REF_STATUS_REJECT_STALE: + case REF_STATUS_REJECT_LAZY_CAS: case REF_STATUS_REJECT_NODELETE: return CHECK_REF_STATUS_REJECTED; case REF_STATUS_UPTODATE: |