Stacked Diffs versus Pull Requests
1–10 of 77 posts
Re: Stacked Diffs versus Pull Requests
#2This is best workflow I've used so far (but usually I had separate branch for really unrelated changes).
Re: Stacked Diffs versus Pull Requests
#3I think I agree with what the author is saying, by and large, but it doesn't matter: if it's a mental model that works for you, you can live in the "stacked diffs" world right up until you need to "curate" all your commits into something that can be considered for incorporation into the parent project.
Then you still need to make a branch, put all the related commits into it in order, and adequately test that branch before sumbitting it.
At that point, if changes are requested, you can make a choice about whether to work by rebasing that branch, or work on your "master" branch and then re-curate those commits. Now, working in the stacked diffs world seems like more work, but you do you.
A place I disagree with the author is about rebasing frequently onto master. Assume you are working in a healthy project with frequent and largely bug-free releases, but occasional trouble during development cycles where tests end up red for awhile despite everyone's best efforts. In this situation, you are better off starting your work from a quality release tag with no red; occasionally you'll end up dealing with more merge conflicts when you're ready to merge the branch, but IMO not so much that you don't derive benefit from avoiding all those rebases onto a new upstream revision that just might be totally bonkers.
If you do this, you should still validate that your branch, merged with or rebased onto master, doesn't make any new test failures or interact destructively with other work; deferring this to the end DOES have a cost, but in my experience it is outweighed by the benefits.
(And if you're in one of those now-rare projects where it's the norm to be making point releases of one or more old releases, PLUS having new development on a master branch, basing your branch at the right place means you can merge it into the old releases with ease...)
Re: Stacked Diffs versus Pull Requests
#4I think I agree with what the author is saying, by and large, but it doesn't matter: if it's a mental model that works for you, you can live in the "stacked diffs" world right up until you need to "curate" all your commits into something that can be considered for incorporation into the parent project. Then you still need to make a branch, put all the related commits into it in order, and adequately test that branch…
Hm, I thought the idea is that the only way something will land in master is if it reviews OK and CI passes all the tests on top of the current master?
Re: Stacked Diffs versus Pull Requests
#5This is a great model that scales very well to the largest projects and most complicated refactors. In fact, it forces you to think about your refactors differently, and that is actually great. You learn to boil the ocean incrementally more.
We got the decentralized workflows alongside concepts like pull requests... but there's no real reason why you can't use your decentralized workflows with trunk based development. The secret, is combining the two: decentralized workflow for local development, with modern CI and code review, that all lead into the trunk.
I've personally been veering toward this model for a while, and it's also somewhat similar to what Google is doing[1], and it works great across a lot of different circumstances.
[1]: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
Re: Stacked Diffs versus Pull Requests
#6> How do you git bisect a codebase where every 6th commit doesn’t build because it was jammed into the middle of a Pull Request?
This I think is the main problem with pull requests. A better default would be squashing the commits into a single one after review.
Re: Stacked Diffs versus Pull Requests
#7> How do you git bisect a codebase where every 6th commit doesn’t build because it was jammed into the middle of a Pull Request? This I think is the main problem with pull requests. A better default would be squashing the commits into a single one after review.
This is also suboptimal. I’d rather each commit be an atomic unit: no larger and no smaller than it needs to be.
Edit: in other words, concurring with TFA.
Re: Stacked Diffs versus Pull Requests
#8I think I agree with what the author is saying, by and large, but it doesn't matter: if it's a mental model that works for you, you can live in the "stacked diffs" world right up until you need to "curate" all your commits into something that can be considered for incorporation into the parent project. Then you still need to make a branch, put all the related commits into it in order, and adequately test that branch…
[deleted]
Re: Stacked Diffs versus Pull Requests
#9> How do you git bisect a codebase where every 6th commit doesn’t build because it was jammed into the middle of a Pull Request? This I think is the main problem with pull requests. A better default would be squashing the commits into a single one after review.
This is also suboptimal. I’d rather each commit be an atomic unit: no larger and no smaller than it needs to be. Edit: in other words, concurring with TFA.
Sure, but the best way to get there in my mind is `rebase -i`, which means you've made a few and revised a few commits along the way.
Re: Stacked Diffs versus Pull Requests
#10This is very long and i'm tired, is there a more condensed resource?