Hi Patrick, On Mon, 5 May 2025, Patrick Steinhardt wrote: > On Sun, May 04, 2025 at 10:19:06AM +0200, Johannes Schindelin wrote: > > > > On Fri, 2 May 2025, BERENDSEN Arnoud wrote: > > > > > [... talks about `git svn` not working in Git for Windows ...] > > > > In Git for Windows, `git svn` is quite a maintenance burden [... then > > suggests to use Windows System for Linux (WSL) as a workaround ...]. > > I sometimes wonder whether we should move such basically-unmaintained > scripts out of the Git repository. They do a disservice to both us and > to our users as they create the wrong impression of being the sanctioned > way of doing a particular task even though they have only been gathering > dust for ages. > > Many of the tools in "contrib/" fall into this category, and to the best > of my knowledge there isn't really a clear strategy for that directory. > So from my perspective, we should either rethink whether it is worth it > to have "contrib/" as part of Git, or we should at least do a spring > cleanup and drop bits that haven't seen any love in the last couple of > years. While I am thoroughly sympathetic to the idea of cleaning up `contrib/` (which is a mixture of things that are quite well supported, such as the Bash tab completion script, and of things that are the opposite of maintained, such as `contrib/workdir/` that should have been dropped a long time ago since it encourages relying on Git's internals and has been superseded by `git worktree`), I cannot fail to notice that `git-svn` isn't even in `contrib/`. Instead, `git-svn` is in the same category as `git-archimport`, `git-cvsserver`, `git-cvsexportcommit` and `git-cvsimport`, i.e. Git commands that tried to facilitate transitioning from specific version control systems that had been a lot more common than Git at the time, but no longer are. Maybe `git-svn` is not quite as obsolete as the other commands in that category, but they are all merely dust collectors in Git's codebase. Ciao, Johannes
