I agree with most of the point of the article (I'm a huge Phab fan), but I feel like the explanation of what stack diffs are and why it matters was a bit lackin

I agree with most of the point of the article (I'm a huge Phab fan), but I feel like the explanation of what stack diffs are and why it matters was a bit lacking. I usually describe it by comparing it to floating patches instead of anchored branches: (Phabricator) diffs are more like git patches than commits/branches for review. They can be "grafted" on master or other places by applying the patch anywhere master or local branch, the diff is "floating". PRs are specific commits / commit ranges to review and adopt by merging/rebase-squashing, but are "anchored" to the place they branched off of. This matters most when fixing 1 bug means multiple separate change that would be best staying separate commits, having to make N pull requests that depend on each other leads to rebase/forcepush cascades, which sucks. Having "patches" ready to apply means that halfway through "landing" (closing/merging) the diffs, the remaining diffs can be grafted on actual master instead of the (now closed) diff below, instead of having to rebase forever to update Github UI. One major downside of this workflow is that it's different from what git teaches you, so every newcomer needs to learn "the Phab way", which gets people grumpy, and is only realistically feasible in a workplace, not really in a FOSS project as it increases the bar to contribution.