[PATCH v2 00/11] Spring cleanup of "contrib/"
- From
Patrick Steinhardt <ps@pks.im>
- Date
- May 9, 2025, 09:17 UTC
- Message-ID
- <20250509-pks-contrib-spring-cleanup-v2-0-14e20d95ec68@pks.im>
- In-Reply-To
- <20250506-pks-contrib-spring-cleanup-v1-0-e6d5ddd79a72@pks.im>
Hi,
as I have lamented multiple times multiple times already (e.g. [1]), the "contrib/" directory is a bit of a mess containing many bits and pieces that just sit there gathering dust, without getting any maintenance and sometimes even in a clearly-broken state. So I decided to finally bite the bullet and do a spring cleanup of "contrib/", which resulted in this patch series here.
I have used the following reasons for removal:
- The tool is clearly broken, e.g. it doesn't even compile.
- The tool hasn't received any updates for at least the last 5 years.
- The tool has a clear alternative or just isn't useful anymore.
The next step for me would be to spell out a policy around "contrib/" to match what Junio has said [2]:
Things in contrib/ should either move up (to become a part of the
core), move out (to become an independent project), or disappear.With this model, "contrib/" would be closer to Linux' staging drivers with the expectation that a tool should eventually be part of proper Git in case it proves to be useful, or booted out when it doesn't seem to be getting there.
Another subsequent step would be to split out some parts of "contrib/" to be hosted in their own hierarchy. CMake, Coccinelle, Unicode updates, VScode and the like are all tools that are used during development, so they should probably not be part of "contrib/" but rather of a new "tools/" hierarchy (we can bikeshed the name at a later point, I'm not yet doing that in this series).
There's also other bits and pieces that serve as examples. I think we should move these into our documentation instead of having those in "contrib/".
Anway, this series here is just the first step.
Changes in v2:
- Remove "contrib/stats".
- Provide some more details about why specific tools should be safe to
be removed.
- Link to v1: https://lore.kernel.org/r/20250506-pks-contrib-spring-cleanup-v1-0-e6d5ddd79a72@pks.imThanks!
Patrick
[1]: <aBhZHA7av8bWH9Ac@pks.im> [2]: <xmqq5xieq3fs.fsf@gitster.g>
---
Patrick Steinhardt (11):
contrib: remove "remotes2config.sh"
contrib: remove "examples" directory
contrib: remove remote-helper stubs
contrib: remove "thunderbird-patch-inline"
contrib: remove "hooks" directory
contrib: remove "mw-to-git"
contrib: remove "persistent-https" remote helper
contrib: remove "git-resurrect.sh"
contrib: remove "emacs" directory
contrib: remove "git-new-workdir"
contrib: remove "stats" directorycontrib/emacs/README | 33 - contrib/emacs/git-blame.el | 6 - contrib/emacs/git.el | 6 - contrib/examples/README | 20 - contrib/git-resurrect.sh | 181 --- contrib/hooks/multimail/README.Git | 7 - contrib/hooks/post-receive-email | 759 ----------- contrib/hooks/pre-auto-gc-battery | 42 - contrib/hooks/setgitperms.perl | 214 --- contrib/hooks/update-paranoid | 421 ------ contrib/mw-to-git/.gitignore | 2 - contrib/mw-to-git/.perlcriticrc | 28 - contrib/mw-to-git/Git/Mediawiki.pm | 101 -- contrib/mw-to-git/Makefile | 61 - contrib/mw-to-git/bin-wrapper/git | 14 - contrib/mw-to-git/git-mw.perl | 368 ------ contrib/mw-to-git/git-remote-mediawiki.perl | 1390 -------------------- contrib/mw-to-git/git-remote-mediawiki.txt | 7 - contrib/mw-to-git/t/.gitignore | 4 - contrib/mw-to-git/t/Makefile | 32 - contrib/mw-to-git/t/README | 124 -- contrib/mw-to-git/t/install-wiki.sh | 55 - contrib/mw-to-git/t/push-pull-tests.sh | 144 -- contrib/mw-to-git/t/t9360-mw-to-git-clone.sh | 257 ---- contrib/mw-to-git/t/t9361-mw-to-git-push-pull.sh | 24 - contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh | 347 ----- .../mw-to-git/t/t9363-mw-to-git-export-import.sh | 218 --- contrib/mw-to-git/t/t9364-pull-by-rev.sh | 17 - contrib/mw-to-git/t/t9365-continuing-queries.sh | 23 - contrib/mw-to-git/t/test-gitmw-lib.sh | 432 ------ contrib/mw-to-git/t/test-gitmw.pl | 223 ---- contrib/mw-to-git/t/test.config | 40 - contrib/persistent-https/LICENSE | 202 --- contrib/persistent-https/Makefile | 43 - contrib/persistent-https/README | 72 - contrib/persistent-https/client.go | 189 --- contrib/persistent-https/main.go | 82 -- contrib/persistent-https/proxy.go | 190 --- contrib/persistent-https/socket.go | 97 -- contrib/remote-helpers/README | 15 - contrib/remote-helpers/git-remote-bzr | 11 - contrib/remote-helpers/git-remote-hg | 11 - contrib/remotes2config.sh | 33 - contrib/stats/git-common-hash | 26 - contrib/stats/mailmap.pl | 70 - contrib/stats/packinfo.pl | 212 --- contrib/thunderbird-patch-inline/README | 20 - contrib/thunderbird-patch-inline/appp.sh | 55 - contrib/workdir/.gitattributes | 1 - contrib/workdir/git-new-workdir | 105 -- t/meson.build | 1 - t/t1021-rerere-in-workdir.sh | 58 - t/t3000-ls-files-others.sh | 19 - 53 files changed, 7112 deletions(-)
Range-diff versus v1:
1: 2554d816f13 ! 1: f5208d15e68 contrib: remove "remotes2config.sh"
@@ Commit message
mechanism to use config-based remotes. Notably though, the migration
path doesn't even use the migration script. Instead, git-remote(1)
itself knows how to migrate any such remote via `git remote rename`.
- Furthermore, the script hasn't been touched since afa75bc8aa1 (contrib:
- Make remotes2config.sh script more robust, 2007-12-02).
- Given that there is a migration path without this script it is very
- unlikely that anyone still uses the script. Remove it.
+ In fact, a full migration _cannot_ use the script as it only knows to
+ migrate remotes from ".git/remotes/", but not ".git/branches/". As such,
+ the migration path via `git remote rename` is the only feasible way to
+ fully migrate repositories over to the new format.
+
+ Last but not least, the script doesn't even work as-is as it sources
+ "git-sh-setup". For this to work it would need to be invoked either via
+ Git so that this script is in our PATH, users would have to manually
+ call it with an adjusted PATH, or distributions need to install the
+ script into "$prefix/libexec/git-core" with a "git-" prefix. All of
+ these steps are unlikely enough to underpin the claim that this script
+ is not used at all.
+
+ So given that:
+
+ - The script cannot perform a full migration of all deprecated remote
+ types.
+
+ - We don't advertise it anywhere.
+
+ - It has been basically untouched since 2007.
+
+ - It doesn't even work unless users do manual steps.
+
+ It should be safe enough to just remove it. Do so.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
2: bfd219d38e6 = 2: 5da41b6f6ff contrib: remove "examples" directory
3: 23b029002fc = 3: cb0307a65dd contrib: remove remote-helper stubs
4: 2ae101c8533 = 4: 8156f427807 contrib: remove "thunderbird-patch-inline"
5: a2e22a4ce7e = 5: 7fbc6d73eb1 contrib: remove "hooks" directory
6: 54df2acaf10 ! 6: 1267e17e14a contrib: remove "mw-to-git"
@@ Commit message
bitrotting, like e.g. documented in f8ab018dafc (remote-mediawiki tests:
annotate failing tests, 2020-09-21).
- Furthermore, the code has been spun out into a separate project at [2].
- Remove the directory in favor of this new home.
+ According to Matthieu Moy [1], one of the original developers of this
+ tool, it didn't receive any attention recently and there is no
+ motivation to keep maintaining it anymore in the community. The project
+ has been spun out of Git [2] and thus has a new official home, but did
+ not receive much attention over there, either.
+ As such, it seems like the MediaWiki transport helper is slowly fading
+ away. But given that there is a new home, it doesn't make sense to have
+ it as part of Git anymore only to let it rot. Remove the directory.
+
+ [1]: <108f297a-b415-4742-80e4-51ea02af18e9@matthieu-moy.fr>
[2]: https://github.com/Git-Mediawiki/Git-Mediawiki
Signed-off-by: Patrick Steinhardt <ps@pks.im>
7: 80862dd3f3a = 7: 711a73eed73 contrib: remove "persistent-https" remote helper
8: 5bff15bb57c ! 8: 8e5cf72a292 contrib: remove "git-resurrect.sh"
@@ Commit message
e1ff064e1bf (contrib git-resurrect: find traces of a branch name and
resurrect it, 2009-02-04).
- Remove it.
+ Furthermore, the tool does not work with the "reftable" backend at all
+ as it directly reads ".git/logs/HEAD". As reflogs are stored as part of
+ the individual tables though that file wouldn't exist in a "reftable"-
+ enabled repository.
+
+ Last but not least, the tool doesn't even work unless it is explicitly
+ invoked via `git resurrect` as it sources "git-sh-setup". As none of our
+ build systems know to install this script, users thus have to go out of
+ their way to really make it work, which is highly unlikely.
+
+ Another source that indicates that this tool can be removed is a
+ question for how to restore deleted branches on StackOverflow [1]. The
+ top-voted answer uses git-reflog(1) directly and has received more than
+ 3000 votes to date. While "git-resurrect.sh" is also mentioned, it only
+ got 16 upvotes, and comments mention the above caveat that users have to
+ do some manual setup to make it work.
+
+ It's thus rather clear that the tool doesn't have a lot or even any
+ users. Remove it.
+
+ [1]: https://stackoverflow.com/questions/3640764/can-i-recover-a-branch-after-its-deletion-in-git
Signed-off-by: Patrick Steinhardt <ps@pks.im>
9: 8ec63910c32 = 9: ae90457d6cc contrib: remove "emacs" directory
10: 5f673e64206 = 10: a9258add931 contrib: remove "git-new-workdir"
-: ----------- > 11: fda94bd7579 contrib: remove "stats" directory--- base-commit: 6f84262c44a89851c3ae5a6e4c1a9d06b2068d75 change-id: 20250506-pks-contrib-spring-cleanup-bb23b15d6df4