On Tue, Mar 19, 2024 at 05:13:47PM -0400, Eric Sunshine wrote: > On Tue, Mar 19, 2024 at 5:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > > Peff felt that adding `git config --show-hostname-for-includes` was > > > probably overkill, but I'd argue that it is necessary to enable users > > > to deterministically figure out the value to use in their > > > configuration rather than having to grope around in the dark via > > > guesswork and trial-and-error to figure out exactly what works. > > > > > > And the option name doesn't necessarily have to be so verbose; a > > > shorter name, such as `git config --show-hostname` may be good enough. > > > Implementing this option would also obviate the need to implement > > > `test-tool xgethostname` (though, I agree with Junio that `test-tool > > > gethostname` would have been a better, less implementation-revealing > > > name). > > > > Yeah, I like that show-hostname thing (which I do not know if "config" > > is a good home for, though). > > The other possibility which came to mind was adding a GIT_HOSTNAME > variable to the output of `git var -l`. That strikes me as a more appropriate spot than an option to git-config. Even if config is the only thing _now_ which cares about the hostname, it may be something that other parts of the system care about in the future. Some care may need to be taken for error handling, though. For "git var GIT_HOSTNAME" it is OK to exit non-zero, but "git var -l" should not bail on a system where gethostname() doesn't work (it is still not clear to me if that is a real case to worry about or not). -Peff
