mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Drew DeVault <>
Cc:, Stefan Beller <>,
	Junio C Hamano <>
Subject: Re: [PATCH 2/2] send-pack: downgrade push options error to warning
Date: Tue, 18 Feb 2020 00:40:09 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Feb 17, 2020 at 09:44:32AM -0500, Drew DeVault wrote:

> Because the receiving end has to explicitly enable
> receive.advertisePushOptions, and many servers don't, it doesn't make
> sense to set push options globally when half of your pushes are just
> going to die.

This makes me a little nervous, because we don't know what those push
options were supposed to do. Yet we'll proceed with the push minus the
options, which might perform an action that it's hard for the user to
undo. Imagine something as harmless as an option to suppress
notifications to your teammates about a push, or something as dangerous
as one that changes how the push will do an auto-deploy to a production

That latter is probably unlikely, but it feels like we ought to be
erring on the conservative side here, especially since we've had the old
behavior for so many versions.

I do agree that setting push.pushOptions in your global gitconfig is
probably going to be annoying. Even in the repo .git/config, you might
push to multiple remotes, only some of which support the options.

So perhaps it would make sense to do one or both of:

 - allow remote.*.pushOptions for specific remotes

 - add a push.pushOptionIfAble key which behaves similarly to
   push.pushOption, but is quietly ignored if options aren't supported.
   Then you could put options there that you know are safe to be

I'm not sure exactly what kinds of options you want be setting globally,
so I'm not sure which of those would be more useful.


  reply	other threads:[~2020-02-18  5:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-17 14:44 [PATCH 1/2] git-receive-pack: document push options Drew DeVault
2020-02-17 14:44 ` [PATCH 2/2] send-pack: downgrade push options error to warning Drew DeVault
2020-02-18  5:40   ` Jeff King [this message]
2020-02-18 17:44     ` Junio C Hamano
2020-02-18  5:30 ` [PATCH 1/2] git-receive-pack: document push options Jeff King

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).