You are reading content from Scuttlebutt
User has not chosen to be hosted publicly
@cel %VBvrxFGXegQNX+V52nB0jo/YeGMWChtasa+oyuPP4S4=.sha256

@kode54
There should be no problem with a repository being larger then 5MB. The 5MB limit is for a packfile in a single git push. (git-ssb should probably detect and prevent pushes like this). The situation of the repository appearing empty sounds like a bug in git-ssb-web. One possible source for the bug is that git-ssb-web or ssb-git-repo modifies git-update messages that it gets from sbot/ssb-client, and subsequent sbot calls returning those messages return the modified ones as they are cached by leveldb. This needs more investigation but the fix should just be to not modify any objects returned from sbot rpc calls.

User has not chosen to be hosted publicly
@cel %yXbfOKX6wY7Chw/8W6ygI0W+E3AtBFcy3vpInEfulGs=.sha256

@kode54 I reproduced the bug of repos appearing empty in git-ssb-web, and published a fix: %KLhr629.... Does that work for you?

For the first error you mentioned (EPIPE), that may be a trivial bug (output if there is nothing to push) or something else. If it happens again, retry with -vvv git argument so we can see more debug info.

For the second error (mentioning non-fast-forward), that is because git does not let you push a commit to a branch that is not a descendent of the current commit at that branch unless you force-push. To force-push, use -f (e.g. git push -f ssb master) or a plus (e.g. git push ssb +3796b03e7cca3a486a8bbe5974532f14242cea4b:master).

The 5MB limit of packfile blobs does not apply in the case you described. Packfiles in the .git directory are not necessarily what gets published by git-ssb. Also, you don't have to push existing repo content to the fork, because the fork already "inherits" the content and refs of the upstream repo.

@cel %ncInZufVq0E8vCkTXzU/As6qYdj6sdcB9XMZf1bt3PM=.sha256
Join Scuttlebutt now