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

[Jonathan Nieder <jrnieder@gmail.com>]

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.

I like patches 3 and 4 because they warn before taking something out
from people's feet.  So I think this series heads in a good direction.

I wonder if in the endgame we'd want git to still recognize the files,
so it can point people to some documentation on how to convert them to
the supported thing.  That way, when people ask "What do I have to do
to work with my very old git repository using current versions of
git?", the answer could still be "Just use current git --- it will
work in an intuitive way and will give advice when it needs your help,
without you needing to proactively do anything special."

Thanks,
Jonathan