jj-stack 0.1.2__tar.gz → 0.1.3__tar.gz

jj_stack-0.1.3/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,59 @@
+name: Bug report
+description: Report incorrect or surprising jj-stack behavior.
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Before filing, check [Troubleshooting](https://www.serpentine.com/software/jj-stack/troubleshooting/).
+        Many errors end with a `Hint:` that resolves them.
+
+        Do not paste private repository contents, tokens, or internal URLs.
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened
+      description: What you ran, what you expected, and what jj-stack did instead.
+      placeholder: |
+        I ran `jj-stack submit` on a three-change stack and expected ...
+        Instead it ...
+    validations:
+      required: true
+  - type: textarea
+    id: repro
+    attributes:
+      label: Steps to reproduce
+      description: >-
+        The local stack shape and the commands you ran, in order. `jj log` output for the
+        affected stack is usually the most useful thing you can include.
+    validations:
+      required: true
+  - type: textarea
+    id: doctor
+    attributes:
+      label: Output of `jj-stack doctor`
+      description: Run it in the affected repo. It reports repo setup, GitHub access, and leftovers.
+      render: console
+    validations:
+      required: false
+  - type: input
+    id: jj-stack-version
+    attributes:
+      label: jj-stack version
+      description: Output of `jj-stack --version`.
+    validations:
+      required: true
+  - type: input
+    id: jj-version
+    attributes:
+      label: jj version
+      description: Output of `jj --version`.
+    validations:
+      required: true
+  - type: input
+    id: platform
+    attributes:
+      label: Operating system
+      placeholder: macOS 15.5, Ubuntu 24.04, Windows 11
+    validations:
+      required: true

jj_stack-0.1.3/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Documentation
+    url: https://www.serpentine.com/software/jj-stack/
+    about: Guides, command reference, configuration, and automation.
+  - name: Troubleshooting
+    url: https://www.serpentine.com/software/jj-stack/troubleshooting/
+    about: Recovery steps for the common failure symptoms, organized by what you saw.
+  - name: Report a security vulnerability
+    url: https://github.com/bos/jj-stack/security/advisories/new
+    about: Use private vulnerability reporting. Do not open a public issue.

jj_stack-0.1.3/.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,32 @@
+name: Feature request
+description: Suggest a capability or a change to an existing one.
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        jj-stack is deliberately opinionated: one `jj` change is one pull request, and it owns the
+        generated PR branches. [Compare tools](https://www.serpentine.com/software/jj-stack/tool-comparison/)
+        explains what that rules out. A request that conflicts with those choices may still be
+        worth making — say why the stance should change.
+  - type: textarea
+    id: problem
+    attributes:
+      label: The problem
+      description: The workflow you are trying to complete, and where jj-stack gets in the way.
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: What you would like instead
+      description: The behavior you want. Include the command and output you imagine, if you have one.
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: What you do today
+      description: The workaround you currently use, and why it is not good enough.
+    validations:
+      required: false

{jj_stack-0.1.2 → jj_stack-0.1.3}/.github/SECURITY.md

@@ -8,8 +8,8 @@ This project is under active development. Security fixes are supported on `main`
 
 Please do not report security vulnerabilities in public GitHub issues.
 
-Use GitHub's private vulnerability reporting for this repo if it is enabled. If you cannot
-use private reporting, contact the maintainers directly and include:
+Use [private vulnerability reporting](https://github.com/bos/jj-stack/security/advisories/new),
+which is enabled for this repo. Include:
 
 - a description of the issue
 - steps to reproduce or a proof of concept

jj_stack-0.1.3/.github/pull_request_template.md

@@ -0,0 +1,19 @@
+<!--
+See CONTRIBUTING.md. For a substantial change, please open an issue first.
+Commit subjects use `scope: summary`; explain why in the body, wrapped at 72 columns.
+-->
+
+## What this changes
+
+<!-- The user-visible behavior or rule this adds, alters, or fixes. -->
+
+## Why
+
+<!-- The motivation. For a fix, the symptom that is gone. -->
+
+## Checks
+
+- [ ] `just check` passes
+- [ ] `just complexity` passes, or the pull request explains why a budget must change
+- [ ] Documentation updated, or not required by the rules in `AGENTS.md`
+- [ ] Website snapshot refreshed with `just website` if user-facing docs or `--help` changed

{jj_stack-0.1.2 → jj_stack-0.1.3}/.github/workflows/ci.yml

@@ -23,11 +23,12 @@ jobs:
           python-version: "3.14"
 
       - name: Install tokei
-        env:
-          # Must match TOKEI_VERSION in tools/check_complexity.py; the budgets are baselined
-          # against this exact counter. 14.0.0 publishes no prebuilt binaries, so build it.
-          TOKEI_VERSION: 14.0.0
-        run: cargo install tokei --locked --version "$TOKEI_VERSION"
+        run: |
+          TOKEI_VERSION="$(
+            uv run --no-project --python 3.14 python -c \
+              'from tools.check_complexity import TOKEI_VERSION; print(TOKEI_VERSION)'
+          )"
+          cargo install tokei --locked --version "$TOKEI_VERSION"
 
       - name: Install project environment
         run: uv sync --locked
@@ -39,7 +40,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        jj-version: ["v0.44.0"]
+        jj-version: ["v0.45.1"]
         os: [ubuntu-latest, macos-latest, windows-latest]
         python-version: ["3.14"]
     runs-on: ${{ matrix.os }}
@@ -71,7 +72,7 @@ jobs:
   submit-property-smoke:
     runs-on: ubuntu-latest
     env:
-      JJ_VERSION: v0.44.0
+      JJ_VERSION: v0.45.1
 
     steps:
       - name: Check out repo

{jj_stack-0.1.2 → jj_stack-0.1.3}/.github/workflows/codeql.yml

@@ -23,10 +23,10 @@ jobs:
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@v4.37.7
+        uses: github/codeql-action/init@v4.37.8
         with:
           languages: python
           build-mode: none
 
       - name: Analyze
-        uses: github/codeql-action/analyze@v4.37.7
+        uses: github/codeql-action/analyze@v4.37.8

{jj_stack-0.1.2 → jj_stack-0.1.3}/.github/workflows/release.yml

@@ -19,7 +19,7 @@ concurrency:
   cancel-in-progress: false
 
 env:
-  JJ_VERSION: v0.44.0
+  JJ_VERSION: v0.45.1
 
 jobs:
   build:

{jj_stack-0.1.2 → jj_stack-0.1.3}/AGENTS.md

@@ -22,6 +22,7 @@
 - Run the CLI locally with `just run ...` instead of invoking the module or virtualenv path
   directly.
 - Hard-wrap code and markdown files at 98 columns unless a file uses a different convention.
+  Release-note prose follows `docs/internals/releasing.md` and is intentionally unwrapped.
 
 # Commit messages
 

jj_stack-0.1.3/CONTRIBUTING.md

@@ -0,0 +1,74 @@
+# Contributing
+
+Thanks for your interest in `jj-stack`.
+
+## Before you start
+
+Open an issue before writing a substantial change. `jj-stack` is deliberately opinionated about
+what it manages and what it leaves to `jj`, so a feature that fits your workflow may still be out
+of scope. [Compare tools](docs/tool-comparison.md) explains the stance and its trade-offs.
+
+Bug reports, documentation corrections, and small focused fixes are welcome without prior
+discussion.
+
+## Development setup
+
+You need `uv`, `jj` 0.45.1 or newer, and `just`. Then:
+
+```console
+just setup
+```
+
+Run `just` on its own to list every recipe.
+
+## Working on a change
+
+Run the CLI from your checkout with `just run ...` rather than invoking the module or the
+virtualenv path directly:
+
+```console
+just run view
+```
+
+Run the standard Ruff, type-check, and test pass before you finish:
+
+```console
+just check
+```
+
+Run focused tests while you iterate:
+
+```console
+just test tests/unit/test_jj_client.py
+```
+
+CI also enforces the cumulative complexity budgets. Check them locally with `just complexity`
+when the pinned `tokei` is installed. Raising a budget is a design decision, not routine
+maintenance — say why in the pull request.
+
+If your change touches user-facing documentation, refresh the website snapshot with
+`just website` and include the resulting change in the sibling `website` repository.
+
+## Conventions
+
+[`AGENTS.md`](AGENTS.md) is the working agreement for this repo, and it applies to human
+contributors too. It covers commit message format, the 98-column wrap, when documentation
+changes are required, and where each kind of documentation belongs. The internal notes under
+[`docs/internals/`](docs/internals/) cover the design, testing philosophy, and review standard.
+
+The short version:
+
+- Write commit subjects as `scope: summary`, lowercase, no trailing period.
+- Explain *why* the change exists in the body, wrapped at 72 columns.
+- Add tests at the narrowest layer that covers a distinct risk; consolidate overlapping coverage
+  rather than adding parallel cases.
+- Update documentation only when a change adds or alters a supported rule or workflow, or makes
+  an existing statement inaccurate.
+
+## Submitting
+
+Pull requests go to `main`. `jj-stack` is developed with `jj-stack`, so a stacked series of small
+changes is easy to review and very welcome.
+
+By contributing, you agree that your contributions are licensed under the
+[Apache License 2.0](LICENSE).

{jj_stack-0.1.2 → jj_stack-0.1.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: jj-stack
-Version: 0.1.2
+Version: 0.1.3
 Summary: Stacked GitHub pull requests for Jujutsu
 Project-URL: Homepage, https://www.serpentine.com/software/jj-stack/
 Project-URL: Documentation, https://www.serpentine.com/software/jj-stack/
@@ -20,7 +20,7 @@ Classifier: Programming Language :: Python :: 3.14
 Classifier: Topic :: Software Development :: Version Control
 Classifier: Topic :: Software Development :: Version Control :: Git
 Requires-Python: >=3.14
-Requires-Dist: httpxyz<0.32,>=0.31.0
+Requires-Dist: httpx2<3,>=2.12.0
 Requires-Dist: markdown-it-py<5,>=4.0.0
 Requires-Dist: pydantic<3,>=2.13.3
 Requires-Dist: rich<16,>=15.0.0
@@ -37,7 +37,7 @@ matching PRs.
 ### Requirements
 
 - Python 3.14 or newer
-- `jj` 0.44.0 or newer
+- `jj` 0.45.1 or newer
 - GitHub authentication
 
 ### Install
@@ -109,8 +109,8 @@ refresh. Use `jj-stack list` to see every tracked stack in the repo.
 
 ## Mental model
 
-The local `jj` DAG determines which changes form a stack and their order. On GitHub, each change
-gets a stable PR branch and a PR; every PR targets the PR branch below it, except the
+Your local `jj` history determines which changes form a stack and their order. On GitHub, each
+change gets a stable PR branch and a PR; every PR targets the PR branch below it, except the
 bottom PR, which targets trunk by default:
 
 ```text
@@ -178,9 +178,12 @@ gh skill install bos/jj-stack jj-stack
 See the [skill source](https://github.com/bos/jj-stack/blob/main/skills/jj-stack/SKILL.md). In
 my evaluations with Codex and Claude Code, agents with the `jj-stack` skill succeeded in 11/12
 scenarios versus 6/12 without it, with one critical error versus four, using 60% fewer failed
-command attempts and 18% fewer tool calls. (The critical error was due to Claude Haiku
-understanding a rule and ignoring it. I haven't figured out how to get smaller Claude models to
-behave better, and I don't personally use them.)
+command attempts and 18% fewer tool calls. Treat that as a small pilot rather than a published
+benchmark:
+[`evals/jj-stack-skill.md`](https://github.com/bos/jj-stack/blob/main/evals/jj-stack-skill.md)
+gives the evaluation design, but this repo does not include the traces behind those numbers.
+(The critical error was due to Claude Haiku understanding a rule and ignoring it. I haven't
+figured out how to get smaller Claude models to behave better, and I don't personally use them.)
 
 ## Performance
 

{jj_stack-0.1.2 → jj_stack-0.1.3}/README.md

@@ -9,7 +9,7 @@ matching PRs.
 ### Requirements
 
 - Python 3.14 or newer
-- `jj` 0.44.0 or newer
+- `jj` 0.45.1 or newer
 - GitHub authentication
 
 ### Install
@@ -81,8 +81,8 @@ refresh. Use `jj-stack list` to see every tracked stack in the repo.
 
 ## Mental model
 
-The local `jj` DAG determines which changes form a stack and their order. On GitHub, each change
-gets a stable PR branch and a PR; every PR targets the PR branch below it, except the
+Your local `jj` history determines which changes form a stack and their order. On GitHub, each
+change gets a stable PR branch and a PR; every PR targets the PR branch below it, except the
 bottom PR, which targets trunk by default:
 
 ```text
@@ -150,9 +150,12 @@ gh skill install bos/jj-stack jj-stack
 See the [skill source](https://github.com/bos/jj-stack/blob/main/skills/jj-stack/SKILL.md). In
 my evaluations with Codex and Claude Code, agents with the `jj-stack` skill succeeded in 11/12
 scenarios versus 6/12 without it, with one critical error versus four, using 60% fewer failed
-command attempts and 18% fewer tool calls. (The critical error was due to Claude Haiku
-understanding a rule and ignoring it. I haven't figured out how to get smaller Claude models to
-behave better, and I don't personally use them.)
+command attempts and 18% fewer tool calls. Treat that as a small pilot rather than a published
+benchmark:
+[`evals/jj-stack-skill.md`](https://github.com/bos/jj-stack/blob/main/evals/jj-stack-skill.md)
+gives the evaluation design, but this repo does not include the traces behind those numbers.
+(The critical error was due to Claude Haiku understanding a rule and ignoring it. I haven't
+figured out how to get smaller Claude models to behave better, and I don't personally use them.)
 
 ## Performance
 

{jj_stack-0.1.2 → jj_stack-0.1.3}/check.py

@@ -70,10 +70,9 @@ def _build_checks(
     if coverage:
         pytest_command = (
             *pytest_command,
-            "--cov=jj_stack",
-            "--cov-branch",
-            "--cov-report=term-missing",
-            "--cov-report=html:htmlcov",
+            "--cov",
+            "--cov-report=term",
+            "--cov-report=html",
         )
     return (
         ("ruff", ("-m", "ruff", "check")),

{jj_stack-0.1.2 → jj_stack-0.1.3}/complexity-budget.toml

@@ -3,7 +3,7 @@ production = 20_160
 tests = 21_570
 total = 41_833
 merge = 1_682
-governed = 3_315
+governed = 3_869
 governed_module = 502
 checker = 182
 
@@ -12,8 +12,8 @@ c901 = 16
 governed_c901 = 0
 
 [pytest]
-fixed_property = 8
-merge_recovery = 58
+fixed_property = 9
+merge_recovery = 60
 
 [labels]
 production = "Production"
@@ -21,9 +21,9 @@ tests = "Tests"
 total = "Production and tests combined"
 checker = "Complexity checker"
 merge = "Merge command"
-governed = "Merge and recovery code"
+governed = "Merge, recovery, and change-state code"
 c901 = "Production"
-governed_c901 = "Merge and recovery code"
+governed_c901 = "Merge, recovery, and change-state code"
 fixed_property = "Property-test cases"
 merge_recovery = "Merge and recovery cases"
 
@@ -57,6 +57,7 @@ governed = [
   "src/jj_stack/stack/convergence_observation.py",
   "src/jj_stack/stack/global_convergence.py",
   "src/jj_stack/stack/pr_facts.py",
+  "src/jj_stack/stack/change_state.py",
 ]
 fixed_property = [
   "tests/property/test_submit_property_scenarios.py",

{jj_stack-0.1.2 → jj_stack-0.1.3}/docs/AGENTS.md

@@ -35,6 +35,16 @@ implementation — terms a jj user would not know without reading the source:
 The distinction is between standard jj/git vocabulary (fine) and
 `jj-stack`-specific design prose that leaked into the wrong layer (not fine).
 
+Use one name for each recurring concept, in docs, help, and hints alike:
+
+- The record that connects a pull request to a local change is its **saved pull request link**
+  (or "saved link"); the collection is **tracking data**. Do not call it PR identity, saved
+  tracking, or a remembered PR. The verbs are **link** and **relink**, not attach, adopt, or
+  claim.
+- A **direct merge** is one GitHub performs immediately rather than through a merge queue. Say
+  so the first time a page or help text uses the term.
+- Name commands in full in hints and messages: `jj-stack relink`, not `relink`.
+
 ## What belongs here vs. docs/internals/
 
 **`docs/`** — user-facing guides. These files should explain what to do and

{jj_stack-0.1.2 → jj_stack-0.1.3}/docs/README.md

@@ -39,4 +39,5 @@ jj-stack <command> --help
 jj-stack help --all
 ```
 
-State-changing commands also accept `--dry-run` when you want to preview their work.
+`submit`, `merge`, `unstack`, `cleanup`, and `sync` accept `--dry-run` when you want to preview
+their work.

{jj_stack-0.1.2 → jj_stack-0.1.3}/docs/guides/close-or-separate.md

@@ -53,8 +53,11 @@ links:
 jj-stack cleanup <head-change-id>
 ```
 
-Cleanup leaves a PR branch in place if an open pull request still needs it. Close or retarget
-that pull request, then run the same cleanup command again.
+Cleanup keeps a PR branch while another pull request still uses it as its base, because GitHub
+cannot reopen a pull request whose base branch is gone. The message names that pull request.
+Retarget it to trunk; if it is closed, either reopen and retarget it, or delete its head branch.
+Cleanup also keeps a branch while GitHub still groups its pull request in a stack, so run
+`unstack` first. Then run the same cleanup command again.
 
 ## Close an orphaned pull request
 
@@ -66,5 +69,5 @@ directly:
 jj-stack cleanup --pull-request <pr> --close
 ```
 
-This closes your pull request if it is open, then removes its unused branch, stack overview
-comment, and saved link.
+If your pull request is open, this retargets it to trunk and closes it. It then removes its unused
+branch, stack overview comment, and saved link.

jj_stack-0.1.3/docs/guides/continue-a-stack.md

@@ -0,0 +1,66 @@
+---
+title: Continue an existing stack
+linkTitle: Continue an existing stack
+description: Connect this checkout to your existing stack of pull requests on GitHub.
+navGroup: Everyday work
+weight: 70
+---
+
+Use this workflow when you submitted your stack from another machine or checkout and want to work
+on it here.
+
+## Pick a stack
+
+List the active stacks already tracked here and those available only on GitHub:
+
+```console
+jj-stack checkout --pick
+```
+
+Each GitHub row shows the stack number, top pull request, base branch, size, status, and whether
+the stack is already tracked here, partly tracked, or available only on GitHub. Choosing a stack
+that is not fully tracked here records its pull request links, fetches any missing commits, and
+runs `jj edit` on its top open change. Choosing a stack that is already tracked here just edits
+its head change.
+
+## Connect a pull request directly
+
+Choose any pull request in your stack:
+
+```console
+jj-stack checkout --pull-request <pr>
+```
+
+`checkout` follows that pull request down to the bottom of its stack, fetches those commits,
+records which local change belongs to each pull request, and runs `jj edit` on its change.
+
+To start a new change on top instead of editing that change directly, run:
+
+```console
+jj new
+```
+
+## If your change is already here with local edits
+
+If this repo already has a different commit for the same change, usually because you edited it
+after it was last submitted, `checkout` brings in the pull request's commit as a second copy of
+that change and prints both commit IDs. It does not choose between them. Compare the two, then
+abandon the one you do not want by its commit ID:
+
+```console
+jj log -r 'change_id(<change-id>)'
+jj diff -r <commit-id>
+jj abandon <unwanted-commit-id>
+```
+
+If you kept your own copy, update the pull request:
+
+```console
+jj-stack submit <head-change-id>
+```
+
+## If someone pushed a commit to your PR branch
+
+A commit that someone else pushed to your PR branch, such as a reviewer's suggestion, is not part
+of your change. `checkout` brings it in as a new change on top of yours and prints the
+`jj squash` command that folds it into your change.

{jj_stack-0.1.2 → jj_stack-0.1.3}/docs/guides/merge-and-sync.md

@@ -29,8 +29,8 @@ By default, `merge` starts with the pull request at the bottom of your stack—t
 trunk—and works upward. It merges your ready pull requests in order until your whole stack is
 merged or it reaches a pull request that it cannot merge.
 
-To merge only the bottom portion of your stack, specify its last change by change ID, commit ID,
-or pull request ID:
+To merge only the bottom portion of your stack, name the last change to merge, either as a
+revset or by its pull request:
 
 ```console
 jj-stack merge --pull-request 42
@@ -52,6 +52,16 @@ After GitHub merges some or all of your pull requests, `sync` fetches trunk, rem
 changes from your local history if needed, rebases your remaining changes, updates your remaining
 pull requests, and removes your PR branches when they are no longer needed.
 
+Select the stack by its head change ID or by any linked pull request:
+
+```console
+jj-stack sync <head-change-id>
+jj-stack sync --pull-request <pr>
+```
+
+Unlike `merge --pull-request`, which stops at the selected PR, `sync --pull-request` selects the
+complete local stack containing that PR. The selected PR can already be merged.
+
 If none of the pull requests in your stack has merged and GitHub has not rebased the stack,
 `sync` reports that there are no merged changes and leaves the pull requests unchanged. Run
 `submit` explicitly when you want to publish local changes.
@@ -64,21 +74,18 @@ trunk. `sync` discards the old changes for you.
 
 ### Direct merges
 
-For a direct merge, `merge` waits for GitHub to finish and runs `sync` before it returns. You do
-not need to run another cleanup command.
+A direct merge is one that GitHub performs immediately, rather than through a merge queue. For a
+direct merge, `merge` waits for GitHub to finish and runs `sync` before it returns. You do not
+need to run another cleanup command.
 
 ### Merge queues
 
 When `merge` uses a merge queue, it returns successfully once GitHub accepts the pull requests
 you asked it to merge. This does not mean trunk has changed. Wait until GitHub reports that your
-stack has merged. Then run `sync` with the head of your stack:
-
-```console
-jj-stack sync <head-change-id>
-```
+stack has merged. Then run `sync` for that stack.
 
-If you run either command while one of those pull requests is queued, `submit` and `sync` leave
-your stack unchanged.
+While those pull requests are waiting in the queue, `submit` and `sync` leave your stack
+unchanged.
 
 ### Merges outside jj-stack
 
@@ -88,11 +95,7 @@ same `sync` command after GitHub reports that the merge finished.
 ### Rebasing from GitHub
 
 GitHub's **Rebase stack** action rewrites every PR branch onto the latest trunk. After it
-finishes, run:
-
-```console
-jj-stack sync <head-change-id>
-```
+finishes, run `sync` for that stack.
 
 GitHub does not retain jj change IDs in those rewritten commits. `sync` verifies that the PRs,
 branch order, and contents still match your submitted stack, rebases the original local changes,
@@ -113,9 +116,9 @@ to it. It also removes branches, comments, and saved pull-request links for merg
 local changes are gone. If one stack cannot be updated, jj-stack explains why and continues with
 independent stacks.
 
-`sync --all` and `sync <head-change-id>` do not rebase a stack merely because trunk advanced.
-`sync <head-change-id>` also recognizes a completed native GitHub stack rebase because GitHub
-moved every PR branch and the rewritten contents can be verified.
+Neither form of `sync` rebases a stack merely because trunk advanced. `sync --all` applies
+completed merges only; after GitHub's **Rebase stack** action, run `sync <head-change-id>` for
+that stack.
 
 ## If `merge` fails after GitHub merges your pull requests
 
@@ -139,7 +142,7 @@ command.
 changes with `jj` if needed, then submit the rewritten changes:
 
 ```console
-jj rebase -r '<bottom-change-id>::<head-change-id>' -o 'trunk()'
+jj rebase -s '<bottom-change-id>' -o 'trunk()'
 jj-stack submit <head-change-id>
 ```
 

{jj_stack-0.1.2 → jj_stack-0.1.3}/docs/guides/review-a-stack.md

@@ -29,9 +29,9 @@ A lower layer can be approved while work continues above it. When merging only p
 merge a contiguous section from the bottom; the remaining pull requests still depend on the
 merged work and the author should run `jj-stack sync` afterward.
 
-Use GitHub's native stack merge controls for merges started in the web UI. The ordinary legacy
-pull request merge API does not implement the same stack operation. For current UI behavior and
-limitations, see GitHub's [stacked pull request guides][github-stacks] for the current controls.
+When merging from the web UI, use the stack's own merge controls. Merging an individual pull
+request with its ordinary merge button or API does not perform the stack merge. GitHub's
+[stacked pull request guides][github-stacks] describe the current controls and their limitations.
 
 ## Configure rules and CI for the final base