threads / patch / 52824

patch, 2 partsgit-receive-pack: document push options

Subject: [PATCH 1/2] git-receive-pack: document push options

## tl;dr

5 messages between Feb 17, 2020 and Feb 18, 2020. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Drew DeVault· Feb 17, 2020, 14:44 UTC · lore

This adds the missing documentation on how git push options are presented to the pre-receive hook.

Signed-off-by: Drew DeVault <sir@cmpwn.com>
---
 Documentation/git-receive-pack.txt | 6 ++++++
 1 file changed, 6 insertions(+)

Show changes to Documentation/git-receive-pack.txt +6 −0

diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 25702ed730..69b3e77776 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -109,6 +109,12 @@ the following environment variables:
 This hook is called before any refname is updated and before any
 fast-forward checks are performed.
 
+If the user has specified any push options (see linkgit:git-push[1]),
+`GIT_PUSH_OPTION_COUNT` is set to the number of options, and
+`GIT_PUSH_OPTION_N` is set where N is an integer from 0 thru
+`GIT_PUSH_OPTION_COUNT` - 1. In order for to receive push options,
+`receive.advertisePushOptions` must be enabled on the server.
+
 If the pre-receive hook exits with a non-zero exit status no updates
 will be performed, and the update, post-receive and post-update
 hooks will not be invoked either.  This can be useful to quickly

-- 
2.25.0

Drew DeVault· Feb 17, 2020, 14:44 UTC · re: Drew DeVault · lore

[PATCH 2/2] send-pack: downgrade push options error to warning

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.

Signed-off-by: Drew DeVault <sir@cmpwn.com>
---
 send-pack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Show changes to send-pack.c +1 −1

diff --git a/send-pack.c b/send-pack.c
index 0407841ae8..8c81825e7d 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -439,7 +439,7 @@ int send_pack(struct send_pack_args *args,
 	use_atomic = atomic_supported && args->atomic;
 
 	if (args->push_options && !push_options_supported)
-		die(_("the receiving end does not support push options"));
+		warning(_("the receiving end does not support push options"));
 
 	use_push_options = push_options_supported && args->push_options;

-- 
2.25.0

Jeff King· Feb 18, 2020, 05:40 UTC · re: Drew DeVault · lore

Re: [PATCH 2/2] send-pack: downgrade push options error to warning

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 service.

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
   ignored.

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.

-Peff

Junio C Hamano· Feb 18, 2020, 17:44 UTC · re: Jeff King · lore

Re: [PATCH 2/2] send-pack: downgrade push options error to warning

Jeff King <peff@peff.net> writes:

> This makes me a little nervous, because we don't know what those push
> options were supposed to do.

Thanks for stopping this early.  As you said, this die() is very
much deliberate way for us to make sure that we do not damage an
receiving end that is not prepared.

Show 8 quoted lines

> 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
>    ignored.

Sensible suggestions.

Jeff King· Feb 18, 2020, 05:30 UTC · re: Drew DeVault · lore

Re: [PATCH 1/2] git-receive-pack: document push options

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

Show 16 quoted lines

>  Documentation/git-receive-pack.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
> index 25702ed730..69b3e77776 100644
> --- a/Documentation/git-receive-pack.txt
> +++ b/Documentation/git-receive-pack.txt
> @@ -109,6 +109,12 @@ the following environment variables:
>  This hook is called before any refname is updated and before any
>  fast-forward checks are performed.
>  
> +If the user has specified any push options (see linkgit:git-push[1]),
> +`GIT_PUSH_OPTION_COUNT` is set to the number of options, and
> +`GIT_PUSH_OPTION_N` is set where N is an integer from 0 thru
> +`GIT_PUSH_OPTION_COUNT` - 1. In order for to receive push options,
> +`receive.advertisePushOptions` must be enabled on the server.

Hmm. This is covered already in the pre-receive sections of githooks(7). I wonder if it would be worth consolidating those and having one refer to the other.

I'd be OK just duplicating the content in the meantime, but note that the githooks version covers some more subtleties (like setting the count to 0 when push options are negotiated but none are sent).

If we do go with the text above, there's a typo: s/for to/to/.

-Peff