I think the end goal of this tool is not desirable (to me, at least). The point of grouping together commands like git add and git commit into a single binary is not just to allow you to type git add instead of git-add. The point is that the two subcommands share a ton of logic (parsing and operating on the git file structure). So, if you wanted to compile git-add and git-commit as separate binaries, you would be duplicating the same code for each subcommand. By my count, git has 178 subcommands and the git binary is 4.7MB. So assuming that most of that binary size would be shared by different subcommands, that would be over 800MB of duplicated binaries and a rather annoying build process.
The point is that the two subcommands share a ton of logic (parsing and operating on the git file structure). So, if you wanted to compile git-add and git-commit as separate binaries, you would be duplicating the same code for each subcommand.
Yes, in principle, but that means you have to ship a shared library file in addition to your binaries and those binaries need to be configured to know where to look for the shared library. Definitely doable (easier in some languages than others, like Go, where it’s not normal), but it adds another layer of complexity. It also commits you to designing your code as a shared library/client structure, which may not be a natural structure in your program’s shared code.
Some projects like Busybox have gone to the opposite extreme of bundling hundreds of different unix programs into a single 1.3MB static executable and dispatching to the appropriate tool’s code at runtime based on which symlink invoked it.
I think the end goal of this tool is not desirable (to me, at least). The point of grouping together commands like
git addandgit commitinto a single binary is not just to allow you to typegit addinstead ofgit-add. The point is that the two subcommands share a ton of logic (parsing and operating on the git file structure). So, if you wanted to compilegit-addandgit-commitas separate binaries, you would be duplicating the same code for each subcommand. By my count,githas 178 subcommands and thegitbinary is 4.7MB. So assuming that most of that binary size would be shared by different subcommands, that would be over 800MB of duplicated binaries and a rather annoying build process.score 3 · canonical
Couldn’t the shared logic be a shared library?
score 1 · canonical
Yes, in principle, but that means you have to ship a shared library file in addition to your binaries and those binaries need to be configured to know where to look for the shared library. Definitely doable (easier in some languages than others, like Go, where it’s not normal), but it adds another layer of complexity. It also commits you to designing your code as a shared library/client structure, which may not be a natural structure in your program’s shared code.
Some projects like Busybox have gone to the opposite extreme of bundling hundreds of different unix programs into a single 1.3MB static executable and dispatching to the appropriate tool’s code at runtime based on which symlink invoked it.
score 1 · canonical