From: Junio C Hamano Date: Wed, 08 Apr 2026 18:59:10 GMT Subject: Re: [PATCH 0/4] fetch: add --must-have and remote.*.mustHave Message-ID: In-Reply-To: "Derrick Stolee via GitGitGadget" 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?