On Mon, May 05, 2025 at 09:36:06AM +0200, Johannes Schindelin wrote: > 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/`. Oh, right you are! > 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. Fully agreed. Patrick
