Discussion
electrum: Does Stage work for PRs that have multiple commits? These could be considered "stacked diffs", but in the same PR.
sebakubisz: Can reviewers adjust the chapter splits manually if they disagree with how it grouped the PR, or are the chapters fixed once generated?
dean_stratakos: We don't support that currently, but would love to see examples where you disagree with the chapters so we can figure out the best interfaceYou can regenerate the chapters anytime, but it might lead to similar results as the first time
ryanjso: I like the chapters thing, a lot of PRs I review should really be like 5 prs so its nice to have it auto split like that.Do you see a world where it splits them up on the git level?
tasuki: > a lot of PRs I review should really be like 5 prsCan't you push back on that? I feel like this tool is trying to fix misbehaved colleagues...
embedding-shape: It's an interesting idea, but I feel like it's missing almost the most important thing; the context of the change itself. When I review a change, it's almost never just about the actual code changes, but reviewing it in the context of what was initially asked, and how it relates to that.Your solution here seems to exclusively surface "what" changes, but it's impossible for me to know if it's right or not, unless I also see the "how" first and/or together with the change itself. So the same problem remains, except instead of reviewing in git/GitHub/gerrit + figure out the documents/resources that lays out the task itself, I still have to switch and confirm things between the two.
phyzix5761: This is a really cool idea but where's the moat? What's stopping someone from replicating the functionality?
tasuki: > Stage automatically analyzes the diff, clusters related changes, and generates chapters.Isn't that what commits are for? I see no reason for adding this as an after-thought. If the committers (whether human or LLM) are well-behaved, this info is already available in the PR.
kvdveer: I feest that grouping related changes in commits can be challenging, as git really presents commits as grouping in time, not topic.It is certainly possible to do topic-grouping in commits, but it requires significant effort to het that consistent on a team level.
dean_stratakos: In our experience, it's difficult to create well-mannered commits as you code and new ideas pop into your head or you iterate on different designs (even for LLMs). One concept we toyed around with was telling an LLM to re-do a branch using "perfect commits" right before putting up a PR. But even then you might discover new edge cases and have to tack them on as additional commits.We thought git wasn't the right level of abstraction and decided to tackle things at the PR level instead. Curious to hear your experiences!
nathannaveen: I assume this problem could be solved if we write up what we actually want (like a GH issue) and maybe in the future the guys at Stage could use github issues as part of their PR review?
ryanjso: Yeah, but we're a small company and sometimes cut corners to move faster, so if a tool can solve this instead of potentially adding more friction to other engineers I'm all for it.
cpan22: We're adding functionality to 1. regenerate the chapters manually if you don't like them and 2. support some sort of CHAPTERS.md file that lets you specify how you want things broken down!
kylestlb: I assume Gitlab/Github will add these sort of features to their products within the next few months
dean_stratakos: It's possible, but at the same time it's been years and they haven't copied things like Graphite's dashboard or stacked PR interface yet. We have the advantage of speed :)
cpan22: I agree, that's also really important and something we're brainstormingCurrently on Stage we also generate a PR summary next to the chapters and that's where we want to do more "why" that pulls in context from Linear, etc.And I know there's a lot of cool teams working on embedding agent context into git history itself so that could an interesting area to explore as well
