> Identify which of the files should be modified first.<p>I'm curious how many software engineers work this way — i.e. you need to make a big change, and you can determine a sequential order in which to make changes?<p>My working style is mostly jumping back-and-forth across all the relevant files and tests as I go, realizing new things that I need to change, and iterating until it all works end-to-end.<p>Am I the outlier, or is Maiao's expected workflow the outlier?
Some high-level description is what this actually does would be useful.<p>The main problem with "stacked diffs" or "dependent pull reviews" on GitHub is that they don't work with forks/clones.<p>That is: you can push a branch to your personal clone and then submit a PR against the main repository's development branch. That works fine.<p>You can push two stacked branches into the main repository and set up dependent pull requests (where pr1 targets the main development branch and pr2 targets pr1). That sort of works -- lots of things could be improved about the UI of that workflow, but it's at least possible to do.<p>You <i>can't</i> reasonably push two stacked branches to your personal clone and then set up dependent pull requests against the main development branch: pr2 that targets pr1 will simply not show up in the main repository.<p>Given the fact that the original use case of Git is to work with "stacked diffs", it's absolutely mind-blowing that GitHub still has no property sort for it.
This seems like a great tool. I’m personally hooked on the <a href="https://graphite.dev" rel="nofollow">https://graphite.dev</a> CLI and would just like to mention it for comparison.
Or better: do not assign a task requiring 500 line commit. Reviewing stream of though consisting of 10 commits is not very productive as well.<p>Everybody wins if github/gitlab starts to show diffs between `push -f` for a feature branch. Like in gerrit.
How does HN deal with refactorings that litterally touch 90% of the code, but just 3 lines?<p>Huge PR to refactor, and fatigue sets in. But we cannot PR chunks because the build cannot fail.
I use spr and git fixup for this workflow and it's really helped me breakup my changes better, managing multiple branches and stacking changes that way is a huge pain, but this workflow has been huge for me!<p>SPR: <a href="https://github.com/getcord/spr" rel="nofollow">https://github.com/getcord/spr</a><p>Git fixup: <a href="https://github.com/keis/git-fixup" rel="nofollow">https://github.com/keis/git-fixup</a>