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

From: Junio C Hamano <gitster@pobox.com>
Date: May 16, 2017, 00:37 UTC
Message-ID: <xmqq7f1h63h9.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.21.1.1705121216290.146734@virtualbox>

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

Show 10 quoted lines

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