Ramkumar Ramachandra <artag...@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.
--
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
