That's correct. It's only on our roadmap so far (https://jj-vcs.github.io/jj/latest/roadmap/#better-support-f...).

We have also talked about doing something similar for tree objects in order to better support very large directories (to reduce the amount of data we need to transfer for them) and very deep directories (to reduce the number of roundtrips to the server). I think we have only talked about that on Discord so far (https://discord.com/channels/968932220549103686/969291218347...). It would not be compatible with Git repos, so it would only really be useful to teams outside Google once there's an external jj-native forge that decides to support it (if our rough design is even realistic).

This seems all the more reason to spin up an alternative to github but a jj-native forge.

Maybe we can fork something like codeberg's ui but use jj or maybe the jujutsu team can work with codeberg itself? I am pretty sure that codeberg team is really nice and this could be an experimental feature, which if it really needs to can be crowdfunded by community.

I will chip in the first dollar.

Lack of git-lfs support (hack tho it is) is the only thing currently keeping me from trying (and, assuming it's as nice as it seems, using!) jj. Built-in, better large-file support would be amazing, and I'd happily just ditch git completely to gain that. I think there's probably a lot of people in the same boat.