3 ms·

I see, thanks for the information. I often stack 10+ commits, so I don't think your workflow would be reasonable for me. (For example, here, I have 11 finished

I see, thanks for the information. I often stack 10+ commits, so I don't think your workflow would be reasonable for me. (For example, here, I have 11 finished commits and 3 in progress: https://github.com/arxanas/git-branchless/pull/451 https://github.com/arxanas/git-branchless/pull/451 — but I don't actually use stacked PRs on Github, particularly if no one is reviewing my code. Most of my stacking is at work with Phabricator anyways, which handles this better.)

morelisp 4y ago
It’s only necessary to push ten branches, one per commit, if you intend ten separate, let’s say, “review events” though. For that example we would have fewer than that nor would we want that many. I do stack 10+ commits fairly regularly but that may be only 1-2 reviews. (I’m not familiar with Phabricator, only Gerrit and GH/GL, as well as some more manual Workflows.)
- arxanas 4y ago
  Right, in this case, I would prefer 10 separate review events. Other than for code review purposes themselves, I would want CI to run on each of these commits individually, rather than only on the result at the end.
  - dcow 4y ago
    You can click on individual commits in a pull request on GH (and in every single git tool I know) to review each commit individually. A pull request is an abstraction over a set of commits. Sometimes it's 1:1, many times it's not. Some large companies force the issue because even though it is more rigamarole for everyone involved, they can afford it. So then people invent silly scripts and coin entire workflows just so they can "push 10 PRs all at once" because they want the efficiency back that a 1:1 commit to PR policy robbed from them. It's all quite silly. FYI many CI systems support running each commit individually, including GH and GitLab.
    - arxanas 4y ago
      I (and many developers I know) would use the GitHub individual commit review system, but it has a lot of missing features which make it unreasonable to update commits in the PR. For example, if you rewrite one of the commits in a multi-commit PR, then GitHub loses the association and old comments are lost. Similarly, you can't view the diff between an old and new version of a commit. As far as I know, Phabricator does not let you view or comment on individual commits in a code review (which I use at work). Let me know if you know differently and I might switch to doing that. Can you advise me on running CI on each commit in the PR in GitHub? As far as I can see, it's technically possible in that you can run arbitrary code as part of your CI, but there's no convenient way to do it. (In particular, I would want to be able to view the CI runs for each individual commit, i.e. render the little checkmark/x next to each commit in GitHub, which seems like it would require a lot of integration via the API.) One thing that often happens in a stack is the earlier commits are regularly merged into the main branch while the later commits await review. This helps to keep things in sync in a trunk-based development workflow. Is there a way to split out and merge only the earliest (reviewed and accepted) commits, and leave the later commits pending review, in a tool like GitHub? Overall, I would like to be able to use GitHub PRs for big stacks, but there seems to be a lot of friction in doing so, to the point where it's more convenient to adopt an alternate code review tool (like Graphite) or PR management tool.
      - dcow 4y ago
        > As far as I know, Phabricator does not let you view or comment on individual commits in a code review (which I use at work). Let me know if you know differently and I might switch to doing that. Isn't there a "commits" tab when viewing a revision? Also Phabricator is no longer maintained for the last year. > Can you advise me on running CI on each commit in the PR in GitHub? As far as I can see, it's technically possible in that you can run arbitrary code as part of your CI, but there's no convenient way to do it. (In particular, I would want to be able to view the CI runs for each individual commit, i.e. render the little checkmark/x next to each commit in GitHub, which seems like it would require a lot of integration via the API.) You'd use the https://docs.github.com/en/rest/commits/statuses https://docs.github.com/en/rest/commits/statuses API to publish the little checkmark. More info: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks https://docs.github.com/en/pull-requests/collaborating-with-.... However, before you do that, consider: this one I think is a slight impedance mismatch between how users conceptually think about using GH and how GH actions are designed to be triggered. The most simple thing to do if you want every commit checked and tested is just make a GH action that runs your checks on push, which gets run on every commit and updates the status. If you already have a push action, just remove the "main" branch restriction. The PR action is designed to do PR-scoped things. You can, if you really only want to check commits once they are opened for PR, iterate over the commit list and manually trigger workflows to test and check each one (you can even just manually trigger your existing push action if you add the manual trigger option and specify the commit sha yourself and it will run, I think). But, is the list of commits that get pushed to the repo and the list of commits you want to eventually test for inclusion into main really that different, at the end of the day?

morelisp 4y ago

It’s only necessary to push ten branches, one per commit, if you intend ten separate, let’s say, “review events” though. For that example we would have fewer than that nor would we want that many. I do stack 10+ commits fairly regularly but that may be only 1-2 reviews. (I’m not familiar with Phabricator, only Gerrit and GH/GL, as well as some more manual Workflows.)

arxanas 4y ago
Right, in this case, I would prefer 10 separate review events. Other than for code review purposes themselves, I would want CI to run on each of these commits individually, rather than only on the result at the end.
- dcow 4y ago
  You can click on individual commits in a pull request on GH (and in every single git tool I know) to review each commit individually. A pull request is an abstraction over a set of commits. Sometimes it's 1:1, many times it's not. Some large companies force the issue because even though it is more rigamarole for everyone involved, they can afford it. So then people invent silly scripts and coin entire workflows just so they can "push 10 PRs all at once" because they want the efficiency back that a 1:1 commit to PR policy robbed from them. It's all quite silly. FYI many CI systems support running each commit individually, including GH and GitLab.
  - arxanas 4y ago
    I (and many developers I know) would use the GitHub individual commit review system, but it has a lot of missing features which make it unreasonable to update commits in the PR. For example, if you rewrite one of the commits in a multi-commit PR, then GitHub loses the association and old comments are lost. Similarly, you can't view the diff between an old and new version of a commit. As far as I know, Phabricator does not let you view or comment on individual commits in a code review (which I use at work). Let me know if you know differently and I might switch to doing that. Can you advise me on running CI on each commit in the PR in GitHub? As far as I can see, it's technically possible in that you can run arbitrary code as part of your CI, but there's no convenient way to do it. (In particular, I would want to be able to view the CI runs for each individual commit, i.e. render the little checkmark/x next to each commit in GitHub, which seems like it would require a lot of integration via the API.) One thing that often happens in a stack is the earlier commits are regularly merged into the main branch while the later commits await review. This helps to keep things in sync in a trunk-based development workflow. Is there a way to split out and merge only the earliest (reviewed and accepted) commits, and leave the later commits pending review, in a tool like GitHub? Overall, I would like to be able to use GitHub PRs for big stacks, but there seems to be a lot of friction in doing so, to the point where it's more convenient to adopt an alternate code review tool (like Graphite) or PR management tool.
    - dcow 4y ago
      > As far as I know, Phabricator does not let you view or comment on individual commits in a code review (which I use at work). Let me know if you know differently and I might switch to doing that. Isn't there a "commits" tab when viewing a revision? Also Phabricator is no longer maintained for the last year. > Can you advise me on running CI on each commit in the PR in GitHub? As far as I can see, it's technically possible in that you can run arbitrary code as part of your CI, but there's no convenient way to do it. (In particular, I would want to be able to view the CI runs for each individual commit, i.e. render the little checkmark/x next to each commit in GitHub, which seems like it would require a lot of integration via the API.) You'd use the https://docs.github.com/en/rest/commits/statuses https://docs.github.com/en/rest/commits/statuses API to publish the little checkmark. More info: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks https://docs.github.com/en/pull-requests/collaborating-with-.... However, before you do that, consider: this one I think is a slight impedance mismatch between how users conceptually think about using GH and how GH actions are designed to be triggered. The most simple thing to do if you want every commit checked and tested is just make a GH action that runs your checks on push, which gets run on every commit and updates the status. If you already have a push action, just remove the "main" branch restriction. The PR action is designed to do PR-scoped things. You can, if you really only want to check commits once they are opened for PR, iterate over the commit list and manually trigger workflows to test and check each one (you can even just manually trigger your existing push action if you add the manual trigger option and specify the commit sha yourself and it will run, I think). But, is the list of commits that get pushed to the repo and the list of commits you want to eventually test for inclusion into main really that different, at the end of the day?