Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > You probably forgot that I already proposed that, long time ago: > https://public-inbox.org/git/cover.1494509599.git.johannes.schindelin@xxxxxx/ No, I haven't. It was actually meant as an invitation to you to help us come up with a reasonable deprecation path. I'd be super happy if we did not have to support 3 sources and instead just 2 sources of the remote information, but as I said number of times in the previous attempts' discussion, I think it is trickier than any of our past migration (like "push.default") to remove support for .git/branches, as I see no reasonably convenient alternative/workaround for those who do take advantage of the fact that .git/branches/ is "one liner, single file per remote source", which would make it convenient when you need to interact with dozens of sublevel integrators and the population of them changes regularly. "Run 'git remote add' with these options to limit its scope to a single branch" is easy to say but cumbersome to execute. The best case scenario I came up with is to start giving a message when we read *and* *use* information from .git/branches/ hierarchy (i.e. when we know we found a potential user who will get affected by removal of .git/branches support), asking to tell us not to go forward with the removal if and only if an alternative we leave for them gives them unacceptably high cost (i.e. "we cannot afford to migrate our workflow not to use .git/branches/ because ..."), and after a few releases we do not hear anything from anybody. The second best would be to see responses that can serve as concrete examples to build our easy-to-use alternative after removing the support for .git/branches/. The alternative might end up not removing the support, but that is OK---we are in far better position than we currently are either way. The reason why we still have the support is mainly because we know there were users who took active advantage of that facility (again, not Cogito) several years ago, and we do not know if they moved on to update their workflows to use the config-based settings. After the above (or something similar) happens, we will know that nobody needs it and we can remove it with confidence.
