Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 12 May 2017, Junio C Hamano wrote:
>
>> Is it really hurting us having to support these old information
>> sources we treat as read-only?
>
> Well, you frequently complain about my patches, claiming that they place
> unnecessary maintenance burden on you.
>
> I would say that the .git/remotes/ and .git/branches/ code is a lot more
> maintenance burden than most of my patches.

I wasn't going to respond to this thread anymore, because I didn't
feel like the discussion was going anywhere, and you already said
you won't listen to me.

You seem to be confused between "maintenance burden" and "burden on
the maintainer". I felt that it needs to be corrected for other
people reading this exchange from the sideline.

    When we worked to add feature X in the remotes subsystem, we
    were slowed down because we had to adjust the code also for
    .git/branches.  The same story for feature Y.  The same for
    feature Z.  This is getting ridiculous/cumbersome, especially
    given that we know .git/branches is not used by anybody.

That's a maintenance burden, and the "we" refers to the Git
development community as a whole, not the maintainer.  It is not a
burden on _me_.

Also important to notice is I do not know what X, Y and Z are with
respect to .git/branches feature.  That is where "Is it really
hurting?" question comes from, but it hasn't been answered so far.

What's burden on the maintainer is having to engage in a discussion
like this one, to reject an attempt to remove something that is not
demonstratably a maintenance burden, because the maintainer has to
act as the last-resort champion for the end-users, when others on
the list do not speak up X-<.

Yes, I know that proving that something we currently support is not
used by anybody is HARD [*1*].  That is why removal is costly.  And
that in turn is why we need to be careful when adding new things and
making changes in general.


[Footnotes]

*1* Removal of "rsync" transport we did recently was a happy but
    rare case.  It has been broken for a few years without anybody
    complaining.