@peacememories, perhaps the numbers 140 MB and 38.7 MB do not look that huge when viewed from an absolute standpoint. From a more relative point of view, they are repectively 2800% and 774% of the default maximum blob size of 5 MB. Another thing to have in mind is that these blobs may be replicated by friends and friends of friends (and perhaps even friends of friends of friends), thus multiplicating the combined storage size on the network.

I am unsure how the mobile client ManyVerse is handling git-ssb blobs, but perhaps also have in mind that some devices may have restrictions on storage capacity and/or network bandwidth (speed and data transfer wise).

We do not currently have a way of replicating parts of blobs. Until we do, I'd say:

1. Be content that not all nodes/peers in the network allow replication of blobs bigger than 5 MB, and be grateful to those that explicitly do.
2. If you feel the number of nodes/peers that allow ‘big blobs’ are too low, please set up additional nodes yourself that have config.blobs.max set to whatever you deem an appropriate size. Such nodes will not only replicate your own big blobs, but also other people's big blobs (i.e., if within their hops radius).

@peacememories,

I guess I'll close this issue because the question itself is answered.

Or perhaps leave it open to remind us all that split blobs could be desirable.

@peacememories You can push the repo in chunks to try to make it produce blobs less than 5 MB. Here are some instructions from %oybMyQ5...:

To push a repo in parts, one way to do it is as follows:

• Set environmental variable DRY_RUN=1 to make git ssb output message content to the terminal instead of publishing it.
• Run git log --oneline to get the list of commits.
• Find an old commit in that list. Run git push ssb <commit>:master to push that commit and its history.
• Check the outputed message for the size of the packfile blob to see if it is below 5MB. If it is above 5MB, try again with an older commit. Otherwise re-run the command with the DRY_RUN env var unset, to publish it for real. Then pick a newer commit and push it.

Alternatively to using the "DRY_RUN" environmental variable, you could use the ssb-publishguard plugin. That lets you review and optionally cancel publishing any message that your ssb app is about to publish.

Making git-ssb automatically split a large packfile is this issue: %Vyh2gmm...

This doesn't appear to work for me. The first run of git push ssb <commit>:master works fine, but then when I try to move <commit> forward for the next run, I get fatal: pack has 1513 unresolved deltas

@xloem ok, sounds like something messed up. I assume this is repo %Tb/JpME.... Cloning it normally fails also, which may be another issue.

I found the upstream repo but have not been able to reproduce the unresolved deltas error. What is the next commit you are trying to push? What is your git version?

Some updates to the chunking instructions:
Instead of picking commits from the log to push, you could push tags. That may be a little more organized, and gets the tags pushed.
If you installed git-ssb from ssb-npm, it will detect and prevent pushing a packfile blob > 5MB (overridable with git push option -o force). So using DRY_RUN=1 is not necessary in that case.

Cloning it normally fails also, which may be another issue.

Fixed in ssb-git-repo v2.11.3. %CXEGvgN... %diQrC49...

#git-ssb