Re: [PATCH v2 11/14] t/t5505-remote: test multiple push/pull in remotes-file

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 23, 2013, 21:49 UTC
Message-ID: <7vr4fsebul.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0nFySj_Xztfwjp=FAhz=dBxgmwZ9YG=PY=7HZLfw0P8aw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> 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.

If you remove tests that configure the remotes via the .git/branches and the .git/remotes mechanism to lose test coverage, and then remove the call to read_branches_file() or read_remotes_file() from remote_get_1(), how would you make sure these tests that originally expected these configuration mechanisms to work notice the change in behaviour?

> Why should I know about this
> fringe feature when I'm reading/writing tests for fetch-merge-logic?

That is exactly why I asked you at the very beginning:

    I say "minor" only because I think the cost of keeping these old
    mechanisms alive is very low (if it is a heavy burden on the
    maintenance, please tell me and how).

If we are not deprecating and keeping them alive, anybody who is touching the codepath to deal with "struct remote" should be at least aware of these mechanisms to keep them working. If it is a heavy burden to do so, then keeping them alive is not "minor" at all.

I've been operating under the assumption, from your response to the message in the original discussion in v1, that we are in agreement that we are not deprecating or removing them.

And if we are deliberately keeping them alive, there is no need for you to paint them "fringe". You may not use it, and you can write in your blog or e-mail or whategver that you do not use it, but that label does not belong to our codebase and documentation as long as we are keeping them as supported feature.

Of course, .git/branches, being a single liner format, will not get extended to support richer features that in-config remotes will learn, so you cannot build on existing tests that use the mechanism to show new features. You would need to introduce tests based on the in-config remotes to demonstrate new features such as the support for triangular workflow.

Because the .git/remotes/ files are designed to be extensible by introducing new fields, theoretically it may be possible to extend it to support new features, but we will not. We will keep existing users' existing use cases before new features are introduced in recent Git alive, without adding anything new. People will be migrated out of these old mechanisms over time that way.