2 ms·
The classic email workflow is either one patch or a patch series. Where each patch becomes a commit. And each patch can be reviewed in isolation (like a commit
by keybored 2y ago
The classic email workflow is either one patch or a patch series. Where each patch becomes a commit. And each patch can be reviewed in isolation (like a commit).
It is not anemic like the squash workflow.
- skydhash 2y agoThere’s nothing stopping anyone from creating a PR series. My reasoning for the squash workflow is described here[0]. I just equate a PR to a patch. And it becomes a commit in the main branch. I don’t really care about the commits in the PR, just like no one cares about the commits that produced the patch in the email workflow. [0]: https://news.ycombinator.com/item?id=41839282 https://news.ycombinator.com/item?id=41839282
- keybored 2y ago> I don’t really care about the commits in the PR, just like no one cares about the commits that produced the patch in the email workflow. They do care. They go through the trouble of reviewing it so that the resulting commit[1] that lands in the upstream repository is good. [1] Presumably you don’t mean “they don’t care about the commit that produced the patch”… since the patch is just a transport format for the commit.
- skydhash 2y ago> Presumably you don’t mean “they don’t care about the commit that produced the patch”… since the patch is just a transport format for the commit. Commits. Not everyone will care to clean up their local history just to produce a single patch. You can git diff it out. EDIT: I was using "patch" for diff so scratch the above comment. Even then, when using a forge, I'd rather use squash unless everyone clean up their commit history when producing a PR.
- keybored 2y agoThis must mean that you don’t use PRs like the email workflow since nothing of what you’ve described looks like any email workflow that I’ve seen.