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.
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