Why am I griping about Gitee on my own blog instead of reporting it to Gitee? Because that’s one of the things I’m griping about. Their issue workflow is broken too. I filed an issue first — README.md fails to load third-party images — then someone official replied and rejected it. And that’s the problem: once rejected, I had no way to reply. So here I am:
How It Started
Rough version first. Gitee is a code host I started using recently. I’ve been on GitHub for ages, but slow access from China pushed me toward Gitee. Coming in with GitHub habits, I immediately felt that some small details were handled worse. Gitee is something China should be proud of and I want it to get better, so I filed a suggestion issue. Someone official closed it without understanding my point, and then I had no way to keep discussing it.
Now the detailed version.
Since Gitee was new to me and all my code lived on GitHub, I used both during the transition — and that comparison surfaced a few rough edges. My two repos:
GitHub: https://github.com/renfei/Indexing
Gitee: https://gitee.com/rnf/Indexing
Everything looks fine now, but only because I worked around it. Back then:
I embedded an image in README.md, pointing at my CDN: https://cdn.renfei.net/upload/2021/indexing_tools.gif.
When displaying README.md, GitHub rewrites it to its own proxy URL: https://camo.githubusercontent.com/c74d6df72c262ef1742446e34b763713ec97cbf2f260f7064f92b694647efbde/68747470733a2f2f63646e2e72656e6665692e6e65742f75706c6f61642f696d6167652f323032312f696e646578696e675f746f6f6c732e676966
On Gitee the image was simply broken.
I dug in and found that Gitee references my image URL directly, while my CDN has hotlink protection enabled — so because gitee.com was hotlinking my asset, the image request came back 403 and broke.
Having diagnosed it and compared it with GitHub’s approach, I thought GitHub’s way was much better: download the image and rewrite it to their own URL, removing the third-party dependency. Even if the third party enables hotlink protection, images still render.
So I filed an issue on Gitee suggesting they do the same — download and rewrite, or even just reverse-proxy it. That one: README.md fails to load third-party images
What Happened Next
I submitted it and heard nothing for over 24 hours. No follow-up questions if they didn’t understand — it just sat there, rejected and reopened along the way. To make my point clearer I added more description and screenshots:
The Outcome
I ran out of patience and simply whitelisted gitee.com in my CDN so the image would show. Then the official reply arrived:
Data in repositories won’t be processed this way for users. Inappropriate.
And the issue was closed. There was no way to keep the discussion going, because their rule is: issues in the “completed” or “rejected” state don’t accept comments.
But the fix only has to happen in the front-end view when rendering — nobody asked them to modify files in the user’s repo. Stubborn. And this is how GitHub manages it.
The Gripes
I get that words and static screenshots might not convey my intent. But closing it outright so I can’t reply — that arrogance I can’t understand, which is exactly why I’m writing this on my own blog.
Then there’s attachments. Gitee caps their size:
Individual attachments can’t exceed 100 MB (200 MB for GVP projects), and total repo attachments can’t exceed 1 GB (5 GB for recommended projects, 20 GB for GVP). Total attachment quota includes both repo attachments and release attachments.
GitHub doesn’t impose those limits. And since I wanted things easy for users, I packaged the program bundled with a JRE and shipped separate builds for linux_x64, macOS_x64, windows_x64, and windows_x86 — which meant my attachment quota was gone after only a few releases!
5 GB for recommended projects? That’s another gripe: I clicked self-recommend and got zero feedback, no information at all, no way to actually get recommended.
Conclusion
Maybe I’m being harsh on Gitee simply because GitHub is what I know and expect. But I do hope users pushing back helps Gitee go further and get better.