On Sat, Nov 21, 2020 at 07:31:14PM -0800, Junio C Hamano wrote: > >> So that got a bit off-track, but I think: > >> > >> - t1300 already is very much like this, so it's not a new thing > >> > >> - but I would be happy not to see it go further in that direction, > >> even if it means inconsistency with the rest of the script > > > > I agree we shouldn't make things worse. > > I started looking at early parts of t1300 and here is how far I > managed to get before I can no longer keep staring the existing > tests without vomitting. I think my similar gastric reaction is what caused me to stop looking at it long ago. But it may also have been the test brian mentioned that explicitly checks that this case works (and for which he had to set SHA1 prereq). > I am reasonably happy with the "let's keep the vanilla untouched one > in .git/config-initial, refrain from using [core] and other sections > that MUST be in the initial configuration for testing, and use a > wrapper that reads expected addition to the initial one from the > standard input for validation" approach I came up with, but I am not > happy with the name 'compare_expect'; 'validate_config_result' might > be a better name. IMHO this is worse than just using "config --file" in most of the tests. It's more steps to remember to deal with. And most tests do not care at all what the source file is. There are a few that check the order of lookup with respect to system and user files, but they could probably be run what non-destructive changes. That said, most of the effort is in the tedium of switching each individual test. I am happy for whoever volunteers to do that work to have the final say in the approach. -Peff
