From: Karthik Nayak Date: Mon, 09 Mar 2026 10:36:29 GMT Subject: Re: [GSOC][PATCH 1/2] editor: make editor_program local to editor.c Message-ID: In-Reply-To: Burak Kaan Karaçay writes: > On Sun, Mar 01, 2026 at 04:22:38PM +0000, Phillip Wood wrote: >>>While moving the global variable from 'environment.c' to 'editor.c' >>>doesn't cause any behavior change, it still relies on global state. >> >>That's true, but does it really make sense for this config setting >>per-repository? Why would I want to use different editors for >>different repositories in the same process? >> >>Thanks >> >>Phillip > > In practical sense, yes, it's true. Users generally don't use different > editors for different repositories. For repository dependent settings > .editorconfig mostly cover all scenarios. > > However, as far as I know git doesn't have a system-wide only > configuration settings. These changes mostly serve to libification > process of git. If we leave 'core.editor' setting as a global variable > and user tries to interact with multiple repositories that have > different editor configurations using our libified git, it can mix up > the configs of two repositories. > > If we really want to keep these variables independent from repositories, > we should probably prohibit 'core.editor' setting in local repository > configs. Otherwise, leaving it global seems like a weird behavioral > choice. > > Thanks, > Burak Kaan Karaçay I do agree with the point you're making, true isolation for libification would indeed require that this variable is not a global variable. But, while libification is the destination, steps in that direction should be welcome, and I think one step is to simply localize the global variables. Also bloating up `struct repository` without much thought might not be a good decision either.