On Thu, May 05, 2022 at 12:48:50PM +0200, Christian Couder wrote: > On Wed, May 4, 2022 at 4:34 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > > > I am also interested in others' thoughts about this. If no one thinks > > > that a config option could be useful, I am Ok with making it a > > > "--resolve" command line option that can be passed to any Git command > > > similar to "-c <name>=<value>": > > > > > > git --resolve=... <command> [<args>] > > > > Absolutely not. > > > > "git [push|fetch|clone|ls-remote] --dns-pre-resolve=..." that is > > *NOT* git wide, but is only for transport commands might be a > > possibility, but even then, you'd need to invent a way to do the > > same for non cURL transports (we want to be able to pin the IP when > > going over SSH to a certain host, for the same reason) if we promote > > it to an officially supported command line option. > > Ok with renaming and implementing it only in transport commands. I > don't want, and I don't think it should be necessary, to invent a way > to do the same for non cURL transports though. I think it should be Ok > with the doc saying that the option has only been implemented for > HTTP(S) yet and will have no effect when other transports are used. I think it will be better if git aborts with an error if it is used for a transport that it doesn't support, instead of relying in the documentation, though. > If there is a simple way to do the same thing for ssh, then I might > take a look at it later. For "file" or bundle transports, I don't > think it makes sense, and the "git" transport is not used much in big > hosting services where this feature is likely to be used. This seems definitely useful also for ssh which is also used in big hosting services. Ironically, I think would be even more useful for the "git" transport specially because it doesn't have other protections to rely on that would help prevent spoofing (like TLS), which might be also why it is not that widely used anymore. Carlo
