Flag compatibility policy#
pw_ghish: GitHub CLI-like interface for Gerrit code reviews and CI checks
This document outlines the CLI flag compatibility policy for pw_ghish
relative to the official GitHub CLI (gh).
Philosophy & maintenance principles#
pw_ghish is designed to minimize cognitive friction for developers and
autonomous coding agents accustomed to GitHub CLI workflows, while faithfully
respecting the operational reality of Gerrit and LUCI infrastructure.
To ensure long-term stability and avoid divergence bugs, the following rules
govern all flags supported by pw_ghish:
Exact semantic alignment for upstream flags: When a flag exists in upstream GitHub CLI (e.g.
--web,--undo,--comments,--json,--base,--limit,--state),pw_ghishmust provide the same user-facing behavior or a strictly faithful Gerrit equivalent.No silent divergence: A flag must never silently behave differently from its GitHub CLI counterpart. If an upstream flag cannot be supported safely or cleanly in Gerrit,
pw_ghishmust reject it with an explicit error explaining the limitation rather than silently ignoring it or applying unintended behavior.Non-intersecting flags for Gerrit-specific concepts: Gerrit introduces concepts with no direct GitHub analogue (e.g. Commit-Queue voting, thread resolution state, server-side draft comments, hashtags). When adding flags for these concepts,
pw_ghishmust choose non-intersecting flag names that do not conflict with existing or foreseeable upstream GitHub CLI flags.Explicit designation of ghish-only flags: Gerrit-specific flags are explicitly designated as ghish-only in help text, man pages, and this documentation. This clarifies to human developers and GenAI agents which flags are portable to GitHub and which are tailored specifically to the Gerrit/LUCI environment.
Compatibility tiers#
Tier 1: Upstream equivalent flags#
These flags match upstream gh in syntax, type, and semantic outcome:
Command |
Flag |
Behavior |
|---|---|---|
|
|
Opens the change in the web browser. |
|
|
Displays inline review comments and discussion threads. |
|
|
Outputs machine-readable JSON matching the requested fields. |
|
|
Marks the change as draft / work-in-progress (WIP). |
|
|
Filters changes by state ( |
|
|
Limits the number of returned changes. |
|
|
Filters changes by base branch. |
|
|
Filters changes by author. |
|
|
Enables automated submit once CI and reviews pass. |
|
|
Outputs raw patch diff suitable for |
|
|
Polls CI checks until all builders complete. |
Tier 2: Upstream compatible extensions#
These flags extend standard gh commands in a way that remains natural and
consistent with GitHub conventions:
Command |
Flag |
Behavior |
|---|---|---|
|
|
Adds an optional status message when marking ready or moving to WIP. |
|
|
Top-level review comment message (standard in |
|
|
Comment body text (standard in |
|
|
Inline file path and line location for code review comments. |
|
|
Fetches and displays log snippets for failed build steps. |
|
|
Permits pushing multiple local commits as a stacked change series. |
Tier 3: Gerrit-native / ghish-only flags#
These flags control Gerrit-specific or LUCI-specific mechanics. They are chosen specifically to avoid namespace collisions with future GitHub CLI features:
Command |
Flag |
Behavior |
|---|---|---|
|
|
Triggers LUCI Commit-Queue validation (1 = dry run, 2 = submit). |
|
|
Sets the project auto-submit label (e.g. |
|
|
Adds reviewers to the change. |
|
|
Adds users to the carbon-copy (CC) list without requesting review. |
|
|
Publishes all pending draft comments upon pushing the new patchset. |
|
|
Passes raw Git push options (e.g. |
|
|
Saves an inline comment as a private draft rather than publishing immediately. |
|
|
Toggles the Gerrit thread resolution state ( |
|
|
Sets the Gerrit topic string across related changes. |
|
|
Adds or removes Gerrit hashtags. |
Adding new flags in gh-ish#
When adding or proposing a new flag to pw_ghish:
Check official GitHub CLI reference: Consult
gh help <command>to see if an official flag already exists for the desired functionality. If it exists, adopt the exact same flag name, short option, and expected value format.Verify non-intersection: If introducing a Gerrit-specific feature, verify that the proposed flag name does not collide with any current or planned
ghflags.No silent no-ops: Never accept a flag without implementing its behavior. If a flag is added for forward-compatibility, it must perform the operation or explicitly return an unsupported error.