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

[Junio C Hamano <gitster@pobox.com>]

"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?