I think this affects all git repos across the site.
When you clone a repo, you do not have write access by default. When you visit the project's git page (/p/project/code), you will see two clone options: "HTTP" and "git://". If you clone from "git://", everything works initially as expected.
However, if you are later granted write access (for example by becoming an Admin on the project), then you will get an error if you try to push changes with your original "git://" remote url.
fatal: remote error: access denied or repository not exported: /p/project-name/code
What's going on? It's not immediately clear what the problem is. Did I do something wrong?
If you return to the project's git page you will see that the clone options have changed because of your newly granted write access. The "git://" tab has become "RO" (for "read only") and a third tab has been added named "SSH". This tab says "read/write ssh access" and uses the "ssh://" protocol instead of "git://".
If you update your repo's remote url to use the "ssh://" url, then pushes immediately start to work (assuming you have your profile's ssh keys already configured).
git remote set-url origin ssh://username@git.code.sf.net/p/project-name/code
So that leads us to...
Pushes are not ever allowed over the git:// protocol, but nothing on the git pages or in the git error messages suggest this could be a problem.
One possible solution is to drop the git:// protocol altogether. Always show the ssh:// protocol. Never show the git:// protocol. In my testing, if you try to push to the ssh:// remote when you don't have the user permission, this error appears and blocks any writes. Maybe that's good enough?
error: remote unpack failed: unable to create temporary object directory
To ssh://git.code.sf.net/p/activitystream/code
! [remote rejected] ssh-permissions-test -> ssh-permissions-test (unpacker error)
error: failed to push some refs to 'ssh://username@git.code.sf.net/p/project-name/code'
Ticket moved from /p/forge/site-support/25901/
Can't be converted:
Hello,
We are constantly working on improvements that will be helpful to most of our customers.
SourceForge.net staff also pays attention to the voting on Feature Request posts.
But it is not the only factor considered. If we have a good reason, we may reject a suggestion, even if it has high votes.
Sincerely,
SourceForge Support