Github vs. Email Aliases - eviltoast

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
      2
      ·
      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
            ·
            8 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
              ·
              8 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
                ·
                8 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.