from Hacker News

Show HN: Maiao, Stacked Diffs for GitHub

by joaoqalves on 10/8/22, 12:25 PM with 23 comments

• by feifan on 10/8/22, 5:09 PM

  > Identify which of the files should be modified first.

  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?

  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.

  Am I the outlier, or is Maiao's expected workflow the outlier?

• by atq2119 on 10/8/22, 7:51 PM

  Some high-level description is what this actually does would be useful.

  The main problem with "stacked diffs" or "dependent pull reviews" on GitHub is that they don't work with forks/clones.

  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.

  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.

  You can't 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.

  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.

• by joaoqalves on 10/8/22, 12:26 PM

  Relevant link:

  * Stacked diffs vs Pull Requests [1]

  1 - https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

• by fredrikaverpil on 10/8/22, 5:45 PM

  This seems like a great tool. I’m personally hooked on the https://graphite.dev CLI and would just like to mention it for comparison.

• by bvrmn on 10/8/22, 4:23 PM

  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.

  Everybody wins if github/gitlab starts to show diffs between `push -f` for a feature branch. Like in gerrit.

• by WirelessGigabit on 10/8/22, 3:56 PM

  How does HN deal with refactorings that litterally touch 90% of the code, but just 3 lines?

  Huge PR to refactor, and fatigue sets in. But we cannot PR chunks because the build cannot fail.

• by rockwotj on 10/8/22, 7:18 PM

  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!

  SPR: https://github.com/getcord/spr

  Git fixup: https://github.com/keis/git-fixup

• by nichochar on 10/8/22, 6:50 PM

  Check out graphite. Been LOVING it. Team is awesome and product is evolving fast.