RFC: improve stacked commit flow #710
Description
There's been some amount of friction recently around PR sizes.
To reduce some of this friction I made an attempt to practice a "stacked commit" workflow but it's quite onerous because you effectively have to constantly rebase all the feature branches1. Additionally, if you submit each PR as a merge to main, the reviewer sees the entire stack of commits in the GitHub diff UI. So these are impediments to many, small PRs.
The easiest way to allievate the pain and enable smaller stacked diffs is to allow for branches to live here instead of forks. This would enable stacks to be a chain of merge requests, thereby removing overlapping commits in the GitHub diff UI. Then git rebase base_stack --update-refs and git push --atomic origin base_stack stack1 stack2 stack3 --force-with-lease takes care of pushing all local changes to the stack. GitHub also (kindly enough) appropriately changes the base of such branches when PRs are merged (see here). Additionally, it allows for using a tool to managing all of the friction on the submitter side2.
To be honest, I can't actually think of another way to make things smoother (other than continuing to be diligent about rebasing in forks); I started writing this thinking I'd find another way but googling doesn't lead me to believe there really is another way to practice stacked commits from a fork. If the fear is that having branches here instead of forks is that this repo will accumulate lots of stale branches, then speaking for myself I can at least commit to "garbage collecting" my branches regularly, and since there aren't that many people playing in this sandbox anymore it seems it could be sustainable.
Thoughts?
Footnotes
-
Although I did discover
git rebase main --update-refs, which automates some of the pain away (rebasing the entire stack). ↩ -
Such tools can't be used with forks because with GitHub base branches of PRs have to be in the repo that the PR is submitted too. ↩