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.

  • delirious_owl@discuss.online
    link
    fedilink
    arrow-up
    3
    ·
    4 months ago

    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

    • toastal@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      4 months ago

      The mailing list or maintainer email can accept your issues. You don’t have to have a code forge.

        • toastal@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          4 months ago

          Sure. I love being able to browse code without checking out your bloated monorepo, but it isn’t a requirement.

          • delirious_owl@discuss.online
            link
            fedilink
            arrow-up
            2
            ·
            4 months ago

            I mean more about the features that forges provide, not just a WUI for browsing code. Namely: tracking hundreds of issues, PRs, etc

            • toastal@lemmy.ml
              link
              fedilink
              arrow-up
              1
              ·
              4 months ago

              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.