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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2026, 18:59 UTC
Message-ID: <xmqqv7e1xoqp.fsf@gitster.g>
In-Reply-To: <pull.2085.git.1775658970.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 19 quoted lines

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