Is there any stacked-PR methodology consensus?

I’m trying to create my first official GitHub stack right now, and I agree that they seem to have picked the worst of both worlds. Either you stick to the commit-per-PR model of Sapling, jj, Gerrit, etc., with something like a PR URL or Gerrit’s Change-Id trailer or jj’s reverse-hex change IDs to serve as a stable identifier, or you do branch-per-PR but allow manipulating those branches freely. Requiring separate branches and mandating rebases for them is just confusing.

That being said, `gh stack sync` always rebases, which breaks PR review history · Issue #354 · github/gh-stack · GitHub claims to have found a technique which allows you to do merges on stacked PR branches without running into extraneous conflicts. Idk if it’ll break stacked PR lands (such that you’ll have to merge PRs one-by-one instead). I’m going to try it for my stack, and I can report how it ends up working.

1 Like