5 ms·

> You want to split it in multiple commits? Then it probably should have been split in multiple PRs . Sure, but GitHub/GitLab/Gitea don't let you write multipl

> You want to split it in multiple commits? Then it probably should have been split in multiple PRs . Sure, but GitHub/GitLab/Gitea don't let you write multiple PRs that depend on each other easily, like Phabricator/Gerrit/email do. Either it's a mess of branches merging into each other, multiple commits in the same PR, or wait for one PR to be merged before writing the next.

Varriount 3y ago
If your PR is that big and has that many interconnected pieces, then it should probably be broken up and serially merged anyway. Otherwise it becomes a pain for the reviewers to read, and a pain to make any large changes to.
akoboldfrying 3y ago
I think GitHub is pretty good here: If you make PR #1 from branch foo with target main, and PR #2 from branch bar (a descendant of foo) with target foo (that is, a "sub-PR" of #1), then if #1 gets merged first (into main), #2's target branch will auto-update to main, which is exactly what you want. If #2 gets merged first (into foo), then branch foo of course updates to include the commits in bar, which is again what you want. What behaviour were you hoping to see?
- l72 3y ago
  Wow, I didn't realize github did this!
  - akoboldfrying 3y ago
    I was wrong about when GitHub performs the auto-update. It happens not when the PR is merged, but rather when its underlying branch is deleted. From https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request https://docs.github.com/en/pull-requests/collaborating-with-...: >Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch. (This makes more sense, since if you keep the original branch around, it must be because you want to do more with it.)
- progval 3y ago
  Ah, I didn't know that, thanks. Does it work branch "foo" is not in the same repository as "main" (eg. because you don't have write access to the repository)?
  - akoboldfrying 3y ago
    I haven't tried that specific case, but there's no reason for it not to work -- if #1 (you/foo) gets merged first, the only automatic modification that needs to happen is to change #2's target branch from you/foo to them/main, which is no problem since that target branch is just metadata that lives in your repo. (Merging #2 afterwards would again need to be done by someone with write access to them/main, as you'd expect.)
    - progval 3y ago
      I mean, if both branches "foo" and "bar" are in your fork, you can't open a PR in the upstream repo, can you? As soon as I try, GitHub redirects me to my fork to create the PR there
      - akoboldfrying 3y ago
        bar is a descendant of foo, correct? That's the situation I'm talking about. Assuming that's the case, you want to make #2 a local PR anyway -- that is, its source is you/bar and its target is you/foo. Once #1 gets merged to them/main (by someone with the access to the upstream repo, "them"), #2 will (I predict, based on reasons I've already given) automatically become a PR "in" the repo them. That is, its target branch will automatically change to them/main.
        progval 3y ago
        I just tested, and it does not: after merging https://github.com/ZN3val/testrepo/pull/1 https://github.com/ZN3val/testrepo/pull/1, https://github.com/progval/testrepo/pull/2 https://github.com/progval/testrepo/pull/2 is not updated.
- akoboldfrying 3y ago
  Too late to edit my post unfortunately so replying instead: I was wrong about when GitHub performs the auto-update. It happens not when the PR is merged, but rather when its underlying branch is deleted. From https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request https://docs.github.com/en/pull-requests/collaborating-with-...: >Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch. (This makes more sense, since if you keep the original branch around, it must be because you want to do more with it.)
dalore 3y ago
Huh, Gitlab does have "depends on MR" merging which will block until all the dependent MRs have been merged. Including on other projects.
- progval 3y ago
  Either the second one includes the first one's commits so the second one's diff is unreadable, or it doesn't and the CI fails because it's missing the features introduced by the first one (or merge-conflicts).
  - dalore 3y ago
    You can have merge trains where it will build the MR based on the MRs that are merging to master.

Varriount 3y ago

If your PR is that big and has that many interconnected pieces, then it should probably be broken up and serially merged anyway. Otherwise it becomes a pain for the reviewers to read, and a pain to make any large changes to.

akoboldfrying 3y ago

I think GitHub is pretty good here: If you make PR #1 from branch foo with target main, and PR #2 from branch bar (a descendant of foo) with target foo (that is, a "sub-PR" of #1), then if #1 gets merged first (into main), #2's target branch will auto-update to main, which is exactly what you want. If #2 gets merged first (into foo), then branch foo of course updates to include the commits in bar, which is again what you want. What behaviour were you hoping to see?

l72 3y ago
Wow, I didn't realize github did this!
- akoboldfrying 3y ago
  I was wrong about when GitHub performs the auto-update. It happens not when the PR is merged, but rather when its underlying branch is deleted. From https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request https://docs.github.com/en/pull-requests/collaborating-with-...: >Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch. (This makes more sense, since if you keep the original branch around, it must be because you want to do more with it.)
progval 3y ago
Ah, I didn't know that, thanks. Does it work branch "foo" is not in the same repository as "main" (eg. because you don't have write access to the repository)?
- akoboldfrying 3y ago
  I haven't tried that specific case, but there's no reason for it not to work -- if #1 (you/foo) gets merged first, the only automatic modification that needs to happen is to change #2's target branch from you/foo to them/main, which is no problem since that target branch is just metadata that lives in your repo. (Merging #2 afterwards would again need to be done by someone with write access to them/main, as you'd expect.)
  - progval 3y ago
    I mean, if both branches "foo" and "bar" are in your fork, you can't open a PR in the upstream repo, can you? As soon as I try, GitHub redirects me to my fork to create the PR there
    - akoboldfrying 3y ago
      bar is a descendant of foo, correct? That's the situation I'm talking about. Assuming that's the case, you want to make #2 a local PR anyway -- that is, its source is you/bar and its target is you/foo. Once #1 gets merged to them/main (by someone with the access to the upstream repo, "them"), #2 will (I predict, based on reasons I've already given) automatically become a PR "in" the repo them. That is, its target branch will automatically change to them/main.
      - progval 3y ago
        I just tested, and it does not: after merging https://github.com/ZN3val/testrepo/pull/1 https://github.com/ZN3val/testrepo/pull/1, https://github.com/progval/testrepo/pull/2 https://github.com/progval/testrepo/pull/2 is not updated.
akoboldfrying 3y ago
Too late to edit my post unfortunately so replying instead: I was wrong about when GitHub performs the auto-update. It happens not when the PR is merged, but rather when its underlying branch is deleted. From https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request https://docs.github.com/en/pull-requests/collaborating-with-...: >Note: If you delete a head branch after its pull request has been merged, GitHub checks for any open pull requests in the same repository that specify the deleted branch as their base branch. GitHub automatically updates any such pull requests, changing their base branch to the merged pull request's base branch. (This makes more sense, since if you keep the original branch around, it must be because you want to do more with it.)

dalore 3y ago

Huh, Gitlab does have "depends on MR" merging which will block until all the dependent MRs have been merged. Including on other projects.

progval 3y ago
Either the second one includes the first one's commits so the second one's diff is unreadable, or it doesn't and the CI fails because it's missing the features introduced by the first one (or merge-conflicts).
- dalore 3y ago
  You can have merge trains where it will build the MR based on the MRs that are merging to master.