From: Junio C Hamano <gitster@pobox•com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail•com>
Cc: git@vger•kernel.org, "Jeff King" <peff@peff•net>,
"Jakub Narębski" <jnareb@gmail•com>,
"Jacob Keller" <jacob.keller@gmail•com>,
"Matt McCutchen" <matt@mattmccutchen•net>
Subject: Re: [PATCH] push: document & test --force-with-lease with multiple remotes
Date: Sun, 16 Apr 2017 20:56:13 -0700 [thread overview]
Message-ID: <xmqqinm3k7qa.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170408114100.13743-1-avarab@gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Sat, 8 Apr 2017 11:41:00 +0000")
Ævar Arnfjörð Bjarmason <avarab@gmail•com> writes:
> Document & test for cases where there are two remotes pointing to the
> same URL, and a background fetch & subsequent `git push
> --force-with-lease` shouldn't clobber un-updated references we haven't
> fetched.
>
> Some editors like Microsoft's VSC have a feature to auto-fetch in the
> background, this bypasses the protections offered by
> --force-with-lease as noted in the documentation being added here.
That sounds like an unfortunate mix of two "feature"s that are
mutually incompatible. Perhaps those who thought auto-fetch was a
good idea didn't think through the implications, and also it is
understandable that those who never thought auto-fetch was a good
idea would want --force-with-lease to default to the remote-tracking
branch.
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 1624a35888..2f2e9c078b 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -210,6 +210,43 @@ or we do not even have to have such a remote-tracking branch when
> this form is used). If `<expect>` is the empty string, then the named ref
> must not already exist.
> +
> +This option interacts very badly with anything that implicitly runs
> +`git fetch` on the remote to be pushed to in the background. The
This description is not accurate. Only those who do not to specify
what is expected and instead use the remote-tracking branch are
affected (but these random "git fetch" clobbering the
remote-tracking branch is sort of known and expected).
I do not think I would mind if these two new lines were added one
paragraph above, i.e. where "--force-with-lease=<refname>" form is
described. It clearly says "... as the remote-tracking branch we
have for them." and that is the best place to say "This option
interacts badly".
next prev parent reply other threads:[~2017-04-17 3:56 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-08 2:15 Tools that do an automatic fetch defeat "git push --force-with-lease" Matt McCutchen
2017-04-08 7:24 ` Stefan Haller
2017-04-08 7:35 ` Ævar Arnfjörð Bjarmason
2017-04-08 9:29 ` Jeff King
2017-04-08 10:10 ` Jakub Narębski
2017-04-08 11:41 ` [PATCH] push: document & test --force-with-lease with multiple remotes Ævar Arnfjörð Bjarmason
2017-04-09 9:55 ` Simon Ruderich
2017-04-09 11:40 ` Ævar Arnfjörð Bjarmason
2017-04-17 3:56 ` Junio C Hamano [this message]
2017-04-19 9:22 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2017-04-08 21:54 ` Tools that do an automatic fetch defeat "git push --force-with-lease" Jacob Keller
2017-04-08 22:13 ` Jeff King
2017-04-08 22:21 ` Jacob Keller
2017-04-09 8:38 ` Stefan Haller
2017-04-09 8:49 ` Jacob Keller
2017-04-09 11:00 ` Stefan Haller
2017-04-10 8:08 ` Jacob Keller
2017-04-10 9:58 ` Ævar Arnfjörð Bjarmason
2017-04-10 23:33 ` Jacob Keller
2017-04-11 8:51 ` Junio C Hamano
2017-04-12 9:11 ` Stefan Haller
2017-07-06 18:56 ` [PATCH] push: disable lazy --force-with-lease by default Junio C Hamano
2017-07-06 19:38 ` Stefan Beller
2017-07-06 22:39 ` Junio C Hamano
2017-07-06 22:42 ` Stefan Beller
2017-07-10 22:32 ` Stefan Beller
2017-07-07 9:24 ` Stefan Haller
2017-07-07 9:42 ` Jeff King
2017-07-07 9:54 ` Ævar Arnfjörð Bjarmason
2017-07-07 15:15 ` Junio C Hamano
2017-07-15 10:45 ` Ævar Arnfjörð Bjarmason
2017-07-17 17:28 ` Junio C Hamano
2017-07-07 9:39 ` Ævar Arnfjörð Bjarmason
2017-04-11 12:37 ` Tools that do an automatic fetch defeat "git push --force-with-lease" Stefan Haller
2017-04-11 12:37 ` Stefan Haller
2017-04-10 18:31 ` Jeff King
2017-04-11 12:37 ` Stefan Haller
2017-04-11 12:50 ` Jeff King
2017-04-12 9:11 ` Stefan Haller
2017-04-09 8:38 ` Stefan Haller
2017-04-09 8:46 ` Jacob Keller
2017-04-08 8:25 ` Jacob Keller
2017-04-08 9:31 ` Jeff King
2017-04-08 15:03 ` Stefan Haller
2017-04-08 22:03 ` Jeff King
2017-04-08 15:03 ` Stefan Haller
2017-04-08 16:04 ` Ævar Arnfjörð Bjarmason
2017-04-08 17:28 ` Stefan Haller
2017-04-12 9:11 ` Stefan Haller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqinm3k7qa.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=avarab@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jacob.keller@gmail$(echo .)com \
--cc=jnareb@gmail$(echo .)com \
--cc=matt@mattmccutchen$(echo .)net \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox