Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to accomplish "one PR contains multiple commits"? #971

Open
xEtherealx opened this issue Oct 22, 2024 · 0 comments
Open

How to accomplish "one PR contains multiple commits"? #971

xEtherealx opened this issue Oct 22, 2024 · 0 comments

Comments

@xEtherealx
Copy link

xEtherealx commented Oct 22, 2024

I'm looking for advice on a workflow using sapling that accomplishes the following, and with a note [3] to the PM:

  1. Submitting or updating a stack updates base branches for all PRs in the stack [1]
    1. It seems like sl config --local github.pr_workflow single accomplishes this
    2. There are probably gaps in merging the stack; it's possible to do in GH but a pain
  2. Each PR can contain multiple commits [2]
    1. I've tried "follow" but it seems that this is intended to make commits lower in the stack follow a commit that is higher in the stack. A typical workflow is adding commits higher in the stack, so it seems like this feature is linking in the wrong direction for this use case.

Can anyone suggest modifications to what I've tried that might lead to a workable sapling workflow for the use case above?

[1] This is needed because my organization uses GitHub to review PRs, and so we have to avoid overlapping commits
[2] This is needed because reviewing PR revisions is unwieldy in GH if commits are clobbered; the context about what changed since the last revision is lost.
[3] Managing and reviewing in stacks is a workflow that's sorely missing from GH, but many organizations will not bulk move PR review off of GitHub and onto e.g. Reviewstack. In order for that to happen, typically a part of the organization will adopt the new workflow and influence the rest to follow. Without good GitHub PR review interoperability, it's going to be very difficult to make such a transition. The ideal scenario for my organization would be that stacks are created and managed using sapling but in a way that is transparent to PR reviewers, making it possible to adopt sapling incrementally over time and once critical mass is formed, migrating to Reviewstack as the PR review tool would be possible. Even further, if RS was interoperable with GH PR reviews, this would make adoption even more feasible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant