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