Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 13, 2017, 10:13 UTC
- Message-ID
- <xmqqinl53w08.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20170512173846.GA27400@aiede.svl.corp.google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 21 quoted lines
> Johannes Schindelin wrote: >> On Fri, 12 May 2017, Junio C Hamano wrote: > >>> And this one is also important. I do not think we had to touch any >>> code that handles .git/remotes/ or .git/branches when we extended >>> the .git/config based configuration for remotes, simply because the >>> old data source are pretty much frozen read-only places these days. >> >> Okay. But by the same reasoning, I want to hear nothing from you anymore >> about the sort of maintenance burden you talked about in the ssh_variant >> patches. That burden was ridiculously small compared to what you tell me >> you want to keep (and for a single user that may have moved on). Not one >> word. > > I don't understand this argument at all. There are costs and benefits > to removing an existing feature, just like there are costs and benefits > to adding a feature. If I understand the two examples you're comparing > correctly, then the same principle is at play in both: when it is much > more expensive to remove a feature than to not add it in the first > place, a maintainer has to push back on both addition and removal of > features.
FWIW, I do not understand Dscho's argument, either.
And I do agree with you about additions and removals. While these are a bit of apples and oranges comparison, the same principle indeed sits behind them. Incompatible changes, including removal, are costly to existing users, so we want to avoid them or when we cannot avoid them, we try to find a way to alleviate the pain. When adding something new, we try to make sure that the addition will not introduce the need to make incompatible changes in the future.