Junio C Hamano wrote: > I'll reject 04/14 and tweak this patch to use 'next' for the new ref > mappings, not duplicated 'master'. It's a matter of taste: I don't like "realistic" (albeit misleading) values when I'm testing configuration variables, while you think they make the tests more readable. Fine. > Patches 07/14, 12/14, 13/14, and 14/14 are bad idea (these will not > be queued on tonight's pushout of 'pu'; neither 04/14 will be). We > may not be encouraging, but that is very different from deprecating > the original mechanisms. The tests that depend on them to work > should be kept. Otherwise, we will never know when we break them > like we did at df93e33c accidenally. > > If we want to have tests that exercise the equivalents spelled with > the modern in-config mechanism, they should be added as new tests, > not by replacing the existing ones. I disagree. It is trivial to prove that the tests in t/remote will break if this fringe feature breaks: I don't know where "we will never know when we break them" is coming from. Why should I know about this fringe feature when I'm reading/writing tests for fetch-merge-logic? And what is _advantage_ of depending on this fringe feature when testing fetch-merge-logic? More tests break? But whatever. I've already spent more time discussing (bikeshedding?) this series than writing it. I regret having written a stupid cleanup series with no real consequence now; I'll be less likely to make the same mistake again in the future. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html