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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html