Comment by sublinear

If the .git subdir of your LFS submodule is really so large that a --no-checkout clone is unreasonable then you can either prune it down to a more recent date range or squash down commits before pushing and keep your more detailed history local.

The point of a clone without checkout is so you can pick the files you really need. This is not a trivial detail that should be automated away. If the user doesn't know which files matter that's an organizational and project management problem, not a git problem. Developers should absolutely care about such details.

The usual workflow is that you develop a feature branch and only push when you have final changes ready to merge and described by a single or just a few commits so that the history isn't a mess. Someone should be reviewing your changes after all. Git is for versioning, not nightly backups. It's also generally preferred that you commit your project flies for your tools, not the binaries from the build output.

The source is always more important because the goal is to understand and review the changes to the project, not just dump everything in there and make managing the project a nightmare. Your use case sounds unusual and likely caused by many binary file changes being committed frequently. You might be correct that git isn't the right tool for that, but it never claimed to be. This doesn't mean git is a bad tool, but that your workflow doesn't seem to care about reviewing every detail before merge.