Message ID | cover.1628845748.git.dyroneteng@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | packfile-uri: http and https as default value of `--uri-protocol` | expand |
On Fri, Aug 13 2021, Teng Long wrote: > The origin is from the reply by Ævar Arnfjörð Bjarmason: > > https://public-inbox.org/git/87a6m9ru85.fsf@evledraar.gmail.com Thanks, I left some comments, see in particular the one on 1/3, i.e. maybe I'm confused about the goals here. I think the goal here makes sense, but that a better way to do this is to simply add a transfer.packfileURI setting, a boolean that defaults to true. See a similar transfer.bundleURI in a related series of mine: https://lore.kernel.org/git/RFC-patch-07.13-f0e4052de4-20210805T150534Z-avarab@gmail.com/ I.e. in that series I also make use of fetch.uriProtocols to configure bundle-uri, so if it lands it'll be confusing to have a know to tweak bundle-uri, but not packfile-uri. But even without it I think it's a lot less confusing to start introdudcing client-specific settings for things we enable/disable in the protocol explicitly, rather than implicitly by (in this case) setting the allowed list of protocols. So that transfer.{bundleURI,packfileURI}=[bool] suggestion, or perhaps even a more generic setting for directly turning on or off capabilities without having to introduce config handling for each one. E.g. transferCapability.{bundle,packfile}-uri.disable=true. I.e. have serve.c and friends loop through transferCapability.*.disable and handle things accordingly on the client.