A merge queue would allow PRs to be brought into the core branch (develop) following our linear git history (rebase-based), with less effort on part of developers. As more of us work in the same monorepo, the likelihood of needing to rebase after a PR is in increases, and sometimes it's needed multiple times. It may be worthwhile exploring options to keep our git history as we like it, while preventing PRs from requiring rebase-hell. This was one of the potential wins we were hoping for from Graphite, prior to other considerations (cost). Other options are likely available at no cost, especially considering the environmental/government/open-source angle.
As a developer I want low-friction PR merging after approval
because rebasing and waiting on CI/flaky tests can take substantial time
and this will help me to reduce downtime waiting for PRs and automate away 'the boring bits'.
A merge queue would allow PRs to be brought into the core branch (develop) following our linear git history (rebase-based), with less effort on part of developers. As more of us work in the same monorepo, the likelihood of needing to rebase after a PR is in increases, and sometimes it's needed multiple times. It may be worthwhile exploring options to keep our git history as we like it, while preventing PRs from requiring rebase-hell. This was one of the potential wins we were hoping for from Graphite, prior to other considerations (cost). Other options are likely available at no cost, especially considering the environmental/government/open-source angle.
As a developer I want low-friction PR merging after approval because rebasing and waiting on CI/flaky tests can take substantial time and this will help me to reduce downtime waiting for PRs and automate away 'the boring bits'.
Potential options:
Questions to answer: