I'm looking for advice on a workflow using sapling that accomplishes the following, and with a note [3] to the PM:
Submitting or updating a stack updates base branches for all PRs in the stack [1]
It seems like sl config --local github.pr_workflow single accomplishes this
There are probably gaps in merging the stack; it's possible to do in GH but a pain
Each PR can contain multiple commits [2]
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.
I'm looking for advice on a workflow using sapling that accomplishes the following, and with a note [3] to the PM:
sl config --local github.pr_workflow singleaccomplishes thisCan 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.