> On 12 May 2025, at 11:05 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Aditya Garg <gargaditya08@xxxxxxxx> writes: > >>>> On 12 May 2025, at 10:12 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>> "Julian Swagemakers" <julian@xxxxxxxxxxxxxxx> writes: >>> >>>> There are multiple implementations of the hostname command, and they >>>> don't all support `--fqdn`. For example this will not work on Alpine >>>> Linux as well as macOS. >>>> ... >>>> All seem to support `-f` though, maybe that would be the better option. >>> >>> What makes me worried about such a proposed changes is if there are >>> implementations that takes `-f` but uses it to mean something >>> completely different from fqdn, and emits something that looks like >>> a hostname but is not. At least an implementation that takes --fqdn >>> without erroring out would try to give what this code wants to find >>> out (or it is simply crazy), but -f does not feel specific enough. >> >> What we can do is use `hostname -f` for macOS, after all its the only darwin based >> OS used rn, and use hostname --fqdn for Linux. >> >> Although it still leaves out Alpine Linux. > > As long as we record the reasoning behind our decision to use `-f`, > with an explanation like "we can add a configuration to disable this > if an odd platform implementation of `hostname -f` truly misbehaves" > to suggest that we can, if needed, easily give an escape hatch if > this change breaks existing users, I think it is OK to just use > `-f`, which would be the simplest ;-) I thinks its best to use --fqdn if its supported on most Linux distros and -f on macOS. It's not really possible for me to check the result of -f on all Linux distros. Although, we still have valid_fqdn checks in place which should cover up most errors, and as far as I have noticed, distros supporting --fqdn support -f as an alternative. Tbh, your call. The v3 of this patch has hostname -f and v4 has hostname --fqdn for Linux and -f for macOS.
