Github dislikes email “aliases” so much that they will shadow ban your otherwise normal activities for months, and once flagged, support will request not only a “valid” email domain but also that you remove the “alias” email from the account completely.
You must log in or register to comment.
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
- Don’t promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
- 0 users online
- 57 users / day
- 383 users / week
- 1.5K users / month
- 5.7K users / 6 months
- 1 subscriber
- 3.13K Posts
- 78.4K Comments
- Modlog
They mean like I want to be able to open an issue on your instance using an account on my instance. Forjero is working in this
The mailing list or maintainer email can accept your issues. You don’t have to have a code forge.
Theres a reason people do.
Sure. I love being able to browse code without checking out your bloated monorepo, but it isn’t a requirement.
I mean more about the features that forges provide, not just a WUI for browsing code. Namely: tracking hundreds of issues, PRs, etc
There are several independent options for all of those that, while they suck to go to a different site, often do a much better job than the code forge—think how Gerrit makes PRs look foolish, Bugzilla, Trac, Trello, etc. even the humble mailing list. What’s also important to note is a separate servdce offers different (or even better) organization options. Say you wanted a “polyrepo”… well, new you need a separate issues/review for every repository which often doesn’t fit as concerns can apply to mulitple repos (which now that I think about it might be one of those pressures on folks to create monorepos due to tooling lock-in choices from certain forges). That’s not to say there isn’t a cost/benefit to losing the integration of a central spot or less servers to deploy, but it very well could mean that a small orchestra of independent services could better suit a project compared to opting into every feature a code forge is offering.
That is to say, the one feature you see in all code forges—even the simple ones like cgit—is the ability to browse code/commits.