Re: [PATCH 0/4] fetch: add --must-have and remote.*.mustHave

[Derrick Stolee <stolee@gmail.com>]

On 4/8/2026 2:59 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> Based on my understanding, the '--negotiation-tip' option is close but not
>> quite what I want. I could have the client only advertise 'release' and
>> 'main' and never advertise any user branches. But then we'd download all
>> content from each user branch every time it updates. Perhaps this would
>> happen even with opportunistic inclusion of more haves, but I'd like to
>> explore this area more.
>>
>> There's also an issue that the '--negotiation-tip' feature doesn't seem to
>> have a config key that enables it without CLI arguments. This is something
>> that we could consider independently.
>> ...
>> Big picture questions to think about:
>>
>>  * Is this a valuable addition to the fetch negotiation?
>>  * Is the interaction between --must-have and --negotiation-tip correct?
>>  * Is the "must have" name sensical to users? I expect that this only
>>    matters to experts, but I'm open to better names that could be more
>>    self-documenting.
>>  * Should we add a similar config key for --negotiation-tip?
> 
> Just like you, I hate the name "must have", but stepping back a bit,
> would it work if we add a single boolean option that says "use the
> negotiation tips as the primary source of 'have's you'd send, but
> unlike the way how the original negotiation-tip feature worked
> without this bit enabled, which did not send anything other than the
> ones reachable by negotiation tips, do advertise opportunistically
> other tips", essentially turning the existing negotiation-tips
> feature into your must-have feature?  You could even call the option
> "--negotiate-better(=(yes|no))" or something, perhaps?
I like this line of thought. You essentially want to use the existing
scaffolding of the --negotiate-tip option but change it from being a
_maximum set_ to being a _minimum set_.

## Considering --negotiation-tip-mode=<mode>

With that in mind, we could have an option like --negotiation-tip-mode
that takes one of a few options. Here are some word choices that I
immediately thought about:

* maximum|minimum: Are these sets a maximum set to choose from or a
		   minimum set to include?

* restrict|include: Are we restricting the haves to this set, or are
 		    we including these tips by default?

* v1|v2: Use numerical versions to indicate the mode without commentary
	 so it could be extended in the future to v3 or more.

None of these jump out as a clear winner in my head. I'm interested in
more exploration of this space before rerolling.

## To mix modes, or not to mix modes?

One downside of this approach is that it disables the ability to use
both modes, at least in its most obvious implementation. What if someone
wants to force a minimum set of wants but also wants to focus the set
of additional wants to a specific ref space?

Theoretically, we could implement the option to toggle with multiple
options, using

  --negotiation-tip-mode=minimum --negotiation-tip=refs/remotes/origin/main \
  --negotiation-tip-mode=maximum --negotiation-tip=refs/remotes/origin/*

and as we process the --negotiation-tip options we'd put the input data
into different lists. Would this complexity be worth it compared to making
a new set of options?

This also becomes more complicated how to describe the interaction of
these options and any config options that enable them by default. When
exactly does the config get ignored in favor of CLI options?

## Considering --negotiation-(required|restricted)

We could alternatively create two new types of options that are clearly
related:

* --negotiation-restricted works exactly like --negotiation-tips and
  would be a synonym (with the old one being "deprecated" in favor of
  the newer one).

* --negotiation-required works like the --must-have in this series.

---

Thanks for considering these options with me. There is a lot of room
for creativity here. This series isn't even my first attempt at this
functionality because there are so many possible ways to accomplish
this goal.

Thanks,
-Stolee