Hi Junio, On Mon, 28 Nov 2016, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > However, I have been bitten time and again by problems that occurred only > > in production, our test suite (despite taking already waaaaaay too long to > > be truly useful in my daily development) was simply not good enough. > > > > So my plan was different: to let end users opt-in to test this new beast > > thoroughly, more thoroughly than any review would. > > I agree with that 100%. > > [...] > > > And for that, environment variables are just not an option. I need > > something that can be configured in a portable application, so that the > > main Git for Windows installation is unaffected. > > I am not sure I follow here. > > Are you saying that the users who are opting into the experiment > will keep two installations, one for daily use that avoids getting > hit by the experimental code and the other that is used for testing? I have obviously done a real bad job at explaining the Windows situation well enough. Many, many users have multiple installations of Git for Windows. If you have GitHub for Windows and installed the command-line tools: you got one. If you installed Git for Windows, you got another one. If you installed Visual Studio, chances are you have another one. If you got any number of third-party tools requiring Git functionality, you have another one. They all live in separate directories that are their own little pseudo Unix root directory structures, complete with etc/, usr/, var/. Users do not necessarily keep track, or for that matter, are aware of, the multiple different installations. Obviously, I do not want any installation other than the one the user just installed to pick up on the configuration. So the suggestion by both you and Peff, to use an environment variable, which is either global, or requires the user to set it manually per session, is simply not a good idea at all. > > My original "create a file in libexec/git-core/" was simple, did the job > > reliably, and worked also for testing. > > It may have been OK for quick-and-dirty hack during development, but > I do not think it was good in anything released. Well, you say that it is quick and dirty. I say it is the only viable solution I saw so far. All proposed alternative solutions fall flat on their bellies, simply by not working in all the cases I need them to work. As I said elsewhere: I look for a correct solution first, and then I thrive to make it pretty. You start the other way round, and I do not have time for that right now. Ciao, Dscho