Motivation
git-spice is uniquely positioned to sit at the center of the code review
workflow. It is the only genuinely open-source option for stacked code
review, and it already provides a uniform, forge-agnostic interface for
submitting and managing change requests across GitHub, GitLab, and
Bitbucket. That makes it the natural place to offer a uniform code
review and merge experience — not just submission.
Inline (diff-line) review comments are the missing piece of that
experience today. Reviewing a stack means leaving the tool to comment in
the browser, per-forge, with no local or batchable workflow. Adding
first-class comment support lets git-spice own the review loop the same
way it already owns the submission loop.
Just as importantly, a uniform comment API lets other tools participate
in the commenting workflow through git-spice rather than reimplementing
per-forge comment plumbing themselves. The VS Code extension is the
motivating example: it can drive review comments across any supported
forge by going through git-spice, instead of speaking each forge's
review API directly.
Proposal
Add infrastructure for posting, listing, resolving, and editing inline
review comments on pull/merge requests across GitHub, GitLab,
Bitbucket, and ShamHub, plus CLI commands to drive it. Comments can be
staged locally and submitted as a single batched review, mirroring the
stack-oriented model git-spice already uses for submission.
Key pieces:
- A
diffmap package translating working-tree file:line references
into forge inline-comment coordinates (path, line, side) by parsing
unified diff output.
- New optional forge capabilities (
WithInlineComments,
WithThreadResolution, WithCommentEdit) with per-forge
implementations (GitHub GraphQL, GitLab discussions, Bitbucket REST,
ShamHub).
- Local staged-comment storage in the spice state store so review
feedback can be drafted offline and submitted as one review.
- CLI commands for managing and submitting review comments, with
stale/outdated detection from diff state, pr/file scope variants,
and a documented list --json shape for external tooling (such as the
VS Code extension).
Tracked by
Motivation
git-spice is uniquely positioned to sit at the center of the code review
workflow. It is the only genuinely open-source option for stacked code
review, and it already provides a uniform, forge-agnostic interface for
submitting and managing change requests across GitHub, GitLab, and
Bitbucket. That makes it the natural place to offer a uniform code
review and merge experience — not just submission.
Inline (diff-line) review comments are the missing piece of that
experience today. Reviewing a stack means leaving the tool to comment in
the browser, per-forge, with no local or batchable workflow. Adding
first-class comment support lets git-spice own the review loop the same
way it already owns the submission loop.
Just as importantly, a uniform comment API lets other tools participate
in the commenting workflow through git-spice rather than reimplementing
per-forge comment plumbing themselves. The VS Code extension is the
motivating example: it can drive review comments across any supported
forge by going through git-spice, instead of speaking each forge's
review API directly.
Proposal
Add infrastructure for posting, listing, resolving, and editing inline
review comments on pull/merge requests across GitHub, GitLab,
Bitbucket, and ShamHub, plus CLI commands to drive it. Comments can be
staged locally and submitted as a single batched review, mirroring the
stack-oriented model git-spice already uses for submission.
Key pieces:
diffmappackage translating working-treefile:linereferencesinto forge inline-comment coordinates (path, line, side) by parsing
unified diff output.
WithInlineComments,WithThreadResolution,WithCommentEdit) with per-forgeimplementations (GitHub GraphQL, GitLab discussions, Bitbucket REST,
ShamHub).
feedback can be drafted offline and submitted as one review.
stale/outdated detection from diff state,
pr/filescope variants,and a documented
list --jsonshape for external tooling (such as theVS Code extension).
Tracked by
prandfilescope variantslist --jsonshape per extension contract