3 ms·
Looking through the comments, seems like stacked diffs would serve better in a lot of these cases...
by sourcesmith 8y ago
Looking through the comments, seems like stacked diffs would serve better in a lot of these cases...
- alangpierce 8y agoSome background on stacked diffs in case people aren't aware: https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phabricator-diffs-small-d9964f4dcfa6 https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phab... I've been using stacked diffs for years now after trying various other git workflows, and I love the freedom it gives me. I almost always structure my work as a single branch (not a separate branch per feature), one commit per code review, and I'm free to edit, reorder, split, and combine changes as I please (mostly with interactive rebase). When a commit gets accepted, I just move it to the bottom of my stack (if it's not there already) and push it. It makes it easy to split changes into a "pipeline" of logical steps that can each be independently reviewed and landed, with multiple steps in code review at once. I hate it when people treat dependent code reviews as an "advanced feature". They're only advanced if you make your workflow so advanced that they're hard to keep track of (many commits per review, many branches, merge commits). If you keep it simple (one commit per review, always rebase), that simplicity gives you much more power in other areas that IMO are more important. I just wish it wasn't so much of a pain to get working in GitHub.
- fulafel 8y agoStacked diffs seems to be a rebase based workflow, so it has many of the same drawbacks as cherry picking.