Review

Comments that hold their place when the branch moves

A thread is written against one commit. The branch then gains commits, is rebased, or is force pushed. In most forges that is where the conversation goes quiet.

What a thread is anchored to

Four things, not one: a path, a line, a side of the diff, and the commit the comment was written against. The last two are what most implementations skip, and skipping them is why a comment on a removed line reappears under the line that replaced it.

The original anchor is never overwritten. That is what lets an outdated thread still show the code it was actually about.

What happens when the branch moves

The line is followed through the diff between the commit the thread was written against and the current head. Three outcomes, and each one is deliberate.

  • The line is unchanged, so the thread stays where it is
  • The line moved, so the thread moves with it, including across a rename
  • The line is gone, so the thread is marked outdated and stays readable

A thread is never deleted

Losing review history to a rebase is the failure this whole part of the product exists to prevent. A conversation about code that has since changed is still the record of why the code changed, and six months later it is often the only record.

Suggested changes

A suggestion block in a comment can be committed in one click. The parser is deliberately strict: the fence has to open and close on its own lines, and a half-written block is ignored rather than guessed at, because the output of this parser is written into somebody's branch.

Stop losing review history to a rebase

The anchoring rules are pure functions with tests, not best-effort heuristics.

Self-host ReviewOS All features