On Mon, May 12, 2025 at 1:34 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 ;-) The problem is not restricted only to macOS (and Alpine), but more generally to all BSD-lineage `hostname` which does not understand --fqdn but does understand -f.
