Re: [PATCH v2 4/7] remote: add remote.*.negotiationRestrict config
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 15, 2026, 19:16 UTC
- Message-ID
- <xmqqtstc590e.fsf@gitster.g>
- In-Reply-To
- <a731f4fc87ebee71d970d4fcaa36e8d991847984.1776266066.git.gitgitgadget@gmail.com>
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 46 quoted lines
> From: Derrick Stolee <stolee@gmail.com> > > In a previous change, the --negotiation-restrict command-line option of > 'git fetch' was added as a synonym of --negotiation-tips. Both of these > options restrict the set of 'haves' the client can send as part of > negotiation. > > This was previously not available via a configuration option. Add a new > 'remote.<name>.negotiationRestrict' multi-valued config option that > updates 'git fetch <name>' to use these restrictions by default. > > If the user provides even one --negotiation-restrict argument, then the > config is ignored. > > Signed-off-by: Derrick Stolee <stolee@gmail.com> > --- > Documentation/config/remote.adoc | 16 ++++++++++++++++ > builtin/fetch.c | 24 ++++++++++++++++++++++-- > remote.c | 6 ++++++ > remote.h | 1 + > t/t5510-fetch.sh | 22 ++++++++++++++++++++++ > 5 files changed, 67 insertions(+), 2 deletions(-) > > diff --git a/Documentation/config/remote.adoc b/Documentation/config/remote.adoc > index 91e46f66f5..5e8ac6cfdd 100644 > --- a/Documentation/config/remote.adoc > +++ b/Documentation/config/remote.adoc > @@ -107,6 +107,22 @@ priority configuration file (e.g. `.git/config` in a repository) to clear > the values inherited from a lower priority configuration files (e.g. > `$HOME/.gitconfig`). > > +remote.<name>.negotiationRestrict:: > + When negotiating with this remote during `git fetch` and `git push`, > + restrict the commits advertised as "have" lines to only those > + reachable from refs matching the given patterns. This multi-valued > + config option behaves like `--negotiation-restrict` on the command > + line. > ++ > +Each value is either an exact ref name (e.g. `refs/heads/release`) or a > +glob pattern (e.g. `refs/heads/release/*`). The pattern syntax is the > +same as for `--negotiation-restrict`. > ++ > +These config values are used as defaults for the `--negotiation-restrict` > +command-line option. If `--negotiation-restrict` (or its synonym > +`--negotiation-tip`) is specified on the command line, then the config > +values are not used.
This is a tangent, but I wonder what happens when this is set in /etc/gitconfig or ~/.gitconfig by mistake. I personally do not think of any good reason to set it in either of these two places, so it might be fine to declare that we read this only from local configuration file or "git -c var=val" command line, but alternative that is easier to implement would be to allow for a variable definition syntax that allows you to say "forget everything you read so far, clear this multi-valued variable", e.g.
== in /etc/gitconfig ==
[remote "origin"]
negotiationRestrict = refs/pull/* == in .git/config ==
[remote "origin"]
# clear them
negotiationRestrict =
negotiationRestrict = refs/heads/*
negotiationRestrict = refs/tags/*or something like that, perhaps?
It is a shame that our configuration framework do not allow specifying their meanings and semantics to variables like parse-options do (where OPT_STRING_LIST naturally allows --no-negotiation-restrict to act as a way to clear the deck). Because there is no official way to programatically declare that remote.<name>.negotiationRestrict is a multi-valued variable whose values are stored in a string-list, the config callback needs to be coded to implement the behaviour for each variable X-<.