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.

    • Atemu@lemmy.ml
      link
      fedilink
      arrow-up
      17
      ·
      9 months ago

      Federated Git has been a thing ever since git was conceived:

      git send-email
      
      • delirious_owl@discuss.online
        link
        fedilink
        arrow-up
        3
        ·
        9 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
          ·
          9 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
              ·
              9 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
                ·
                9 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
                  ·
                  9 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.