Let’s say a repo named cool-stuff is on github.
I have a fork of cool-stuff and I have submitted a PR associated with my fork of cool-stuff which is waiting to be merged.

Now, there is another independent fork of cool-stuff,say, even-cooler-stuff which works on new features to introduce to cool-stuff. I would like to contribute to the even-cooler-stuff repo but github won’t let me since I already have a fork of cool-stuff.

Is there any way to do what I want like this or should I manually tell the author of even-cooler-stuff the changes I want to do?

  • Aloso@programming.dev
    111·
    1 year ago

    The name “pull request” is actually more accurate, because you ask the upstream repository to git pull the changes from the downstream repo.

    • exu@feditown.comEnglish
      6·
      1 year ago

      Either one works imo, as the maintainer is asked to merge your changes into his repo.

    • Sigmatics@lemmy.ca
      2·
      1 year ago

      It’s only more accurate because they actually put the fork in a “different” repo (which really is the same repo).

      If you only have one repo like in Gitlab, merge request is more accurate.

      • Aloso@programming.devEnglish
        2·
        1 year ago

        Whenever possible, it’s recommended to work in a common Git repository and use branching strategies to manage your work. However, if you do not have write access for the repository you want to contribute to, you can create a fork.

        A fork is a personal copy of the repository and all its branches, which you create in a namespace of your choice. Make changes in your own fork and submit them through a merge request to the repository you don’t have access to.

        https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html

        How is this different from GitHub?

        Just to make sure there’s no misunderstanding: When I want to contribute to a project I’m not involved in, like inkscape, I’m not allowed to create a branch in their repo, so I have to fork it, which creates a copy of the repo, and sets the original repo as a remote.

        Note that git is a distributed VCS that doesn’t distinguish between servers and clients. Forking and cloning are the same operation from a technical perspective, except when you git clone, the copy ends up on your local machine, and when you press the “fork” button, the copy is on a GitHub/GitLab server.