git 5.1.0 → 5.2.0

data/.github/skills/rebase/SKILL.md

@@ -1,148 +0,0 @@
----
-name: rebase
-description: 'Rebases the current branch onto origin/main, resolves rebase conflicts, and force-pushes with lease using non-interactive Git commands that never open an editor. Use when updating a feature branch from main, handling rebase conflicts, or rewriting branch history before updating a pull request.'
----
-
-# Rebase
-
-Rebase the current branch on `origin/main`, resolve conflicts, and force-push
-the rewritten history without opening an editor.
-
-## Contents
-
-- [Contents](#contents)
-- [How to use this skill](#how-to-use-this-skill)
-- [Related skills](#related-skills)
-- [Prerequisites](#prerequisites)
-- [Safety rules](#safety-rules)
-- [Workflow](#workflow)
-- [Step 1: Preflight checks and fetch](#step-1-preflight-checks-and-fetch)
-- [Step 2: Start rebase on origin/main](#step-2-start-rebase-on-originmain)
-- [Step 3: Resolve conflicts and continue](#step-3-resolve-conflicts-and-continue)
-- [Step 4: Verify the rebased branch](#step-4-verify-the-rebased-branch)
-- [Step 5: Force-push with lease](#step-5-force-push-with-lease)
-- [Troubleshooting](#troubleshooting)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context, then invoke it when the current
-branch needs to be rebased onto `origin/main` and pushed.
-
-## Related skills
-
-- [Resolve Feedback](../resolve-feedback/SKILL.md) — follow-up workflow for
-  addressing PR review comments after rebasing
-- [PR Readiness Review](../pr-readiness-review/SKILL.md) — final validation
-  before opening or updating a pull request
-
-## Prerequisites
-
-- `git` is installed and authenticated for the remote.
-- The branch is a topic branch with an upstream on `origin`.
-- The working tree is clean before rebasing.
-
-## Safety rules
-
-These rules are mandatory:
-
-- Never run this workflow on `main` or `4.x`.
-- Always fetch `origin` immediately before rebasing.
-- Always run rebase commands with `GIT_EDITOR=:` and `GIT_SEQUENCE_EDITOR=:` so
-  no editor opens.
-- Force-push only with `--force-with-lease`.
-
-## Workflow
-
-1. [Preflight checks and fetch](#step-1-preflight-checks-and-fetch)
-2. [Start rebase on origin/main](#step-2-start-rebase-on-originmain)
-3. [Resolve conflicts and continue](#step-3-resolve-conflicts-and-continue)
-4. [Verify the rebased branch](#step-4-verify-the-rebased-branch)
-5. [Force-push with lease](#step-5-force-push-with-lease)
-
-## Step 1: Preflight checks and fetch
-
-```bash
-git branch --show-current
-git status --short --branch
-git fetch --prune origin
-```
-
-If the current branch is `main` or `4.x`, stop and ask the user to switch to a
-topic branch first.
-
-If `git status --short --branch` shows uncommitted changes, stop and ask the
-user whether to commit or stash before continuing.
-
-## Step 2: Start rebase on origin/main
-
-```bash
-GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase origin/main
-```
-
-If the command succeeds, continue to Step 4. If it stops with conflicts, go to
-Step 3.
-
-## Step 3: Resolve conflicts and continue
-
-Repeat until the rebase completes:
-
-1. Inspect conflicted files:
-
-   ```bash
-   git status --short
-   ```
-
-2. Edit conflicted files, remove conflict markers, and keep the intended final
-   content.
-
-3. Stage resolved files:
-
-   ```bash
-   git add <resolved-path> [<resolved-path>...]
-   ```
-
-4. Continue the rebase without opening an editor:
-
-   ```bash
-   GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase --continue
-   ```
-
-5. If Git reports an empty patch after conflict resolution, skip that commit:
-
-   ```bash
-   GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase --skip
-   ```
-
-If the rebase cannot be completed safely, abort and report back:
-
-```bash
-git rebase --abort
-```
-
-## Step 4: Verify the rebased branch
-
-```bash
-git status --short --branch
-git merge-base --is-ancestor origin/main HEAD
-git --no-pager log --oneline --decorate --max-count=15
-```
-
-`git merge-base --is-ancestor origin/main HEAD` must exit successfully.
-
-## Step 5: Force-push with lease
-
-```bash
-git push --force-with-lease
-```
-
-If push is rejected, fetch and reconcile remote updates before retrying. Never
-replace this with plain `--force`.
-
-## Troubleshooting
-
-| Issue | Solution |
-| ----- | -------- |
-| Rebase stops with conflicts | Resolve files, `git add`, then run `GIT_EDITOR=: GIT_SEQUENCE_EDITOR=: git rebase --continue`. |
-| Rebase continue opens an editor | Re-run with both `GIT_EDITOR=:` and `GIT_SEQUENCE_EDITOR=:` prefixes. |
-| `--force-with-lease` push rejected | Run `git fetch origin`, inspect divergence, reconcile, and retry `--force-with-lease`. |
-| Need to abandon rebasing attempt | Run `git rebase --abort` and report the reason to the user. |

data/.github/skills/refactor-command-to-commandlineresult/SKILL.md

@@ -1,131 +0,0 @@
----
-name: refactor-command-to-commandlineresult
-description: "Migrates a command class that still performs parsing or custom execution logic to return raw Git::CommandLineResult, moving parsing to facade/parser layers. Use during architectural redesign refactoring."
----
-
-# Refactor Command to CommandLineResult
-
-Migrate a command that still performs parsing or custom execution logic to the
-`Git::Commands::Base` pattern, so command classes return raw
-`Git::CommandLineResult` and parsing moves to facade/parser layers.
-
-## Contents
-
-- [How to use this skill](#how-to-use-this-skill)
-- [Prerequisites](#prerequisites)
-- [Related skills](#related-skills)
-- [Target end state](#target-end-state)
-- [Refactor steps](#refactor-steps)
-- [What to remove from command classes](#what-to-remove-from-command-classes)
-- [What to update in tests](#what-to-update-in-tests)
-- [YARD updates](#yard-updates)
-- [Migration process and internal compatibility](#migration-process-and-internal-compatibility)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context, then invoke it with the command
-class or source file to migrate. Examples:
-
-```text
-Using the Refactor Command to CommandLineResult skill, migrate
-Git::Commands::Stash::Pop to the Base pattern.
-```
-
-```text
-Refactor Command to CommandLineResult: lib/git/commands/branch/delete.rb
-```
-
-The invocation needs the command class name or file path of the command to
-refactor.
-
-## Prerequisites
-
-Before starting, you **MUST** load the following skill(s) in their entirety:
-
-- [YARD Documentation](../yard-documentation/SKILL.md) — authoritative
-  source for YARD formatting rules and writing standards;
-
-## Related skills
-
-- [Command Implementation](../command-implementation/SKILL.md) — canonical class-shape checklist, phased
-  rollout gates, and internal compatibility contracts
-- [Review Arguments DSL](../review-arguments-dsl/SKILL.md) — verifying DSL entries match git CLI
-- [Command Test Conventions](../command-test-conventions/SKILL.md) — unit/integration test conventions for command classes
-- [Facade Implementation](../facade-implementation/SKILL.md) — preserving `Git::Repository::*` return-value contracts
-
-## Target end state
-
-```ruby
-class SomeCommand < Git::Commands::Base
-  arguments do
-    ...
-  end
-
-  # optional for non-zero successful exits
-  # rationale comment
-  # allow_exit_status 0..1
-
-  # @!method call(*, **)
-  #
-  #   @overload call(**options)
-  #
-  #     Execute the git ... command.
-  #
-  #     @return [Git::CommandLineResult]
-end
-```
-
-## Refactor steps
-
-1. Move parsing/transforming logic out of command class into caller/facade/parser.
-2. Replace legacy `ARGS` constant + custom `initialize` with `arguments do` +
-   inheritance from `Base`.
-3. Remove custom `#call` body and add `# @!method call(*, **)` YARD directive.
-4. If command requires non-default success exits, add `allow_exit_status` with
-   rationale comment.
-5. Update callers to consume `CommandLineResult` and parse `result.stdout` where
-   needed.
-
-## What to remove from command classes
-
-- parser invocations
-- output transformation logic
-- `literal` entries for policy/output-control flags (e.g. `literal '--no-edit'`,
-  `literal '--verbose'`, `literal '--no-progress'`, `literal '--no-color'`) —
-  command classes are neutral, faithful representations of the git CLI; convert to
-  `flag_option` / `value_option` so the facade can pass the policy value. See
-  "Command-layer neutrality" in CONTRIBUTING.md.
-- manual `raise_on_failure` / manual exit-code checks (unless temporarily needed in
-  an unmigrated class)
-- duplicated bind/execute logic
-
-## What to update in tests
-
-- unit specs should assert CLI args and `CommandLineResult` behavior
-- remove parsed-object assertions from command unit specs
-- move parsing expectations to parser/facade tests
-- include `raise_on_failure: false` in mocked command expectations
-
-## YARD updates
-
-- update `@return` to `Git::CommandLineResult`
-- keep command-specific `@overload` docs nested under `# @!method call(*, **)` directive
-- ensure `@raise` wording reflects allowed range behavior
-- tag short descriptions must not end with punctuation (no trailing period, comma,
-  or colon)
-- multi-paragraph tag descriptions must have a blank comment line (`#`) between the
-  short description and each continuation paragraph
-
-## Migration process and internal compatibility
-
-See [Command Implementation](../command-implementation/SKILL.md) for the canonical phased rollout checklist
-and internal compatibility contract. In summary:
-
-- **always work on a feature branch** — never commit or push directly to `main`;
-  create a branch before starting (`git checkout -b <feature-branch-name>`) and
-  open a pull request when the slice is ready
-- perform refactor in phased slices (pilot/family)
-- keep each slice independently revertible
-- do not mix unrelated behavior changes with refactor-only changes
-- pass slice gates: `bundle exec rspec`, `bundle exec rake test`,
-  `bundle exec rubocop`, `bundle exec rake yard`

data/.github/skills/release-management/SKILL.md

@@ -1,125 +0,0 @@
----
-name: release-management
-description: "Prepares and publishes new releases of the ruby-git gem including version bumps, changelog updates, tagging, and gem publishing. Use when preparing a release or checking release readiness."
----
-
-# Release Management Workflow
-
-This workflow describes how releases are managed for the ruby-git gem.
-
-## Contents
-
-- [How to use this skill](#how-to-use-this-skill)
-- [Related skills](#related-skills)
-- [How Releases Work](#how-releases-work)
-- [Developer Responsibilities](#developer-responsibilities)
-- [Checking Release Readiness](#checking-release-readiness)
-- [What NOT to Do](#what-not-to-do)
-- [Useful Commands](#useful-commands)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context when preparing a release, verifying
-release readiness, or answering questions about versioning and publishing flow.
-
-## Related skills
-
-- [Dependency Management](../dependency-management/SKILL.md) — dependency updates
-   that affect release content and risk
-- [PR Readiness Review](../pr-readiness-review/SKILL.md) — ensure changes are
-   release-ready before merge
-- [Breaking Change Analysis](../breaking-change-analysis/SKILL.md) — evaluate and
-   communicate major-version impact
-
-## How Releases Work
-
-Releases are **fully automated** via
-[release-please](https://github.com/googleapis/release-please) and the
-`.github/workflows/release.yml` workflow:
-
-1. Developers merge PRs with **conventional commit** messages into `main`
-2. release-please automatically opens (and keeps updated) a **release PR** that
-   bumps `lib/git/version.rb` and regenerates `CHANGELOG.md`
-3. When a maintainer merges the release PR, release-please creates a **GitHub
-   release** with a tag
-4. The workflow then **publishes the gem** to RubyGems.org via `rubygems/release-gem`
-
-Key config files:
-
-| File | Purpose |
-| ---- | ------- |
-| `.release-please-config.json` | Release-please settings (release type, changelog sections, versioning strategy) |
-| `.release-please-manifest.json` | Tracks the current released version |
-| `lib/git/version.rb` | Version constant (updated automatically by release-please) |
-| `CHANGELOG.md` | Release history (updated automatically by release-please) |
-
-The versioning strategy is `prerelease` with `beta` as the prerelease type. The
-config also sets `bump-minor-pre-major: true` and `bump-patch-for-minor-pre-major: true`.
-
-## Developer Responsibilities
-
-The only thing developers need to do for releases is **use conventional commit
-messages**. release-please determines the version bump from commit types:
-
-- `fix:` → **patch** bump
-- `feat:` → **minor** bump
-- `feat!:` or `BREAKING CHANGE:` footer → **major** bump
-
-Everything else (version bump, changelog, tag, gem push) is automated. Do **not**
-manually edit `lib/git/version.rb` or `CHANGELOG.md`.
-
-## Checking Release Readiness
-
-Before a maintainer merges a release PR:
-
-1. **Ensure CI passes on `main`:**
-
-   ```bash
-   bundle exec rake default
-   ```
-
-2. **Review unreleased changes since last tag:**
-
-   ```bash
-   git log $(git describe --tags --abbrev=0)..HEAD --oneline
-   ```
-
-3. **Check for open blockers:**
-
-   ```bash
-   gh issue list --label "bug" --state open
-   ```
-
-4. **Review the release PR** — verify the auto-generated changelog and version
-   bump look correct.
-
-## What NOT to Do
-
-- Do **not** manually bump `lib/git/version.rb` — release-please does this
-- Do **not** manually edit `CHANGELOG.md` — it is auto-generated from commits
-- Do **not** manually create tags — release-please creates them on merge
-- Do **not** manually `gem push` — the workflow handles publishing
-- Do **not** force-push or rebase the release PR — release-please manages it
-
-## Useful Commands
-
-```bash
-# View recent tags
-git tag -l --sort=-v:refname | head -10
-
-# List commits since last release
-git log $(git describe --tags --abbrev=0)..HEAD --oneline
-
-# Compare with previous release
-git diff $(git describe --tags --abbrev=0)..HEAD
-
-# Check current version
-ruby -e "require_relative 'lib/git/version'; puts Git::VERSION"
-
-# View release-please config
-cat .release-please-config.json | jq .
-
-# Build gem locally (for testing only)
-bundle exec rake build
-gem install pkg/git-*.gem
-```

data/.github/skills/resolve-feedback/SKILL.md

@@ -1,288 +0,0 @@
----
-name: resolve-feedback
-description: 'Resolves unresolved pull request review threads on the current branch, folds each fix into the existing commit that last touched the same file, force-pushes with lease, and requests a fresh Copilot review. Use when addressing PR feedback, resolving review comments or threads, amending fixes into prior commits, or asking Copilot to re-review after changes.'
----
-
-# Resolve Feedback
-
-Address the unresolved review threads on the pull request for the current
-branch, folding each fix into the existing commit that last touched the affected
-file, then force-push and request another Copilot review.
-
-## Contents
-
-- [Contents](#contents)
-- [How to use this skill](#how-to-use-this-skill)
-- [Related skills](#related-skills)
-- [Prerequisites](#prerequisites)
-- [Terms](#terms)
-- [Safety and stop points](#safety-and-stop-points)
-- [Workflow](#workflow)
-- [Step 1: Identify the PR and branch](#step-1-identify-the-pr-and-branch)
-- [Step 2: Fetch unresolved review threads](#step-2-fetch-unresolved-review-threads)
-- [Step 3: Triage each thread](#step-3-triage-each-thread)
-- [Step 4: Implement the changes](#step-4-implement-the-changes)
-- [Step 5: Fold each change into the matching commit](#step-5-fold-each-change-into-the-matching-commit)
-- [Step 6: Force-push the branch](#step-6-force-push-the-branch)
-- [Step 7: Reply to and resolve threads](#step-7-reply-to-and-resolve-threads)
-- [Step 8: Request another Copilot review](#step-8-request-another-copilot-review)
-- [Troubleshooting](#troubleshooting)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context and invoke it when a PR has review
-feedback to address on the current branch. Work top to bottom. Stop and ask the
-user whenever a thread needs a clarification or decision (Step 3) and before the
-history-rewriting force-push (Step 6).
-
-## Related skills
-
-- [Pull Request Review](../pull-request-review/SKILL.md) — the review workflow
-  that produces the threads this skill resolves
-- [PR Readiness Review](../pr-readiness-review/SKILL.md) — pre-PR quality gate to
-  run before pushing follow-up changes
-- [Development Workflow](../development-workflow/SKILL.md) — TDD process and
-  branch rules that govern the fixes made here
-
-## Prerequisites
-
-- The `gh` CLI is installed and authenticated (`gh auth status`).
-- The current branch has an open PR and is a topic branch (not `main` or `4.x`).
-- The working tree has no unrelated uncommitted changes before starting.
-
-## Terms
-
-- **Unresolved review thread** — a PR review thread whose `isResolved` is
-  `false` in the GitHub GraphQL API.
-- **Base** — the merge-base between the PR base branch and `HEAD`, computed with
-  `git merge-base origin/<base-branch> HEAD`. All commit lookups are scoped to
-  `<base>..HEAD` so only this branch's commits are considered.
-- **Target commit** — the newest commit in `<base>..HEAD` that last touched the
-  file a fix applies to. Each fix is folded into its target commit.
-
-## Safety and stop points
-
-These rules are mandatory:
-
-- Never rewrite history on `main` or `4.x`. Confirm the branch first with
-  `git branch --show-current`.
-- Stop and ask the user whenever a thread requests a clarification or decision
-  (Step 3). Do not guess on ambiguous feedback.
-- Force-push only with `--force-with-lease`, and only after the user confirms
-  (Step 6).
-- Do not resolve a thread until its fix is committed and pushed (Step 7).
-
-## Workflow
-
-1. [Identify the PR and branch](#step-1-identify-the-pr-and-branch)
-2. [Fetch unresolved review threads](#step-2-fetch-unresolved-review-threads)
-3. [Triage each thread](#step-3-triage-each-thread) — ask for clarifications or
-   decisions as needed
-4. [Implement the changes](#step-4-implement-the-changes)
-5. [Fold each change into the matching commit](#step-5-fold-each-change-into-the-matching-commit)
-6. [Force-push the branch](#step-6-force-push-the-branch)
-7. [Reply to and resolve threads](#step-7-reply-to-and-resolve-threads)
-8. [Request another Copilot review](#step-8-request-another-copilot-review)
-
-## Step 1: Identify the PR and branch
-
-Confirm the branch and locate the PR for it:
-
-```bash
-git branch --show-current
-gh pr view --json number,title,headRefName,baseRefName,url,state
-```
-
-Record the PR number, `baseRefName` (the base branch), and URL. If no PR is
-associated with the branch, stop and tell the user.
-
-## Step 2: Fetch unresolved review threads
-
-List the first 100 review threads and keep the ones where `isResolved` is
-`false`. For unusually active PRs with more than 100 review threads, paginate
-before assuming no unresolved threads remain.
-
-```bash
-OWNER=$(gh repo view --json owner --jq '.owner.login')
-REPO=$(gh repo view --json name --jq '.name')
-PR_NUMBER=$(gh pr view --json number --jq '.number')
-
-gh api graphql -f query='
-  query($owner:String!, $repo:String!, $pr:Int!) {
-    repository(owner:$owner, name:$repo) {
-      pullRequest(number:$pr) {
-        reviewThreads(first:100) {
-          nodes {
-            id
-            isResolved
-            isOutdated
-            path
-            line
-            comments(first:30) {
-              nodes { databaseId author { login } body }
-            }
-          }
-        }
-      }
-    }
-  }' -F owner="$OWNER" -F repo="$REPO" -F pr="$PR_NUMBER" \
-  --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false)'
-```
-
-For each unresolved thread, note its `id` (thread ID, needed to resolve it), the
-first comment `databaseId` (needed to reply), the `path`, and the `line`.
-
-## Step 3: Triage each thread
-
-For each unresolved thread, classify it and act:
-
-- **Actionable and unambiguous** → plan the concrete code or doc change.
-- **Needs a clarification or decision** → stop and ask the user. Present the
-  thread's file, line, and comment text, and the specific question or the
-  options you see. Wait for the answer before implementing.
-- **Not applicable / disagree** → do not change code; draft a short, respectful
-  reply explaining why (used in Step 7). Ask the user if you are unsure whether
-  to push back.
-
-Do not proceed to Step 4 for a thread until its resolution is clear.
-
-## Step 4: Implement the changes
-
-Apply the agreed changes in the workspace. Keep edits for each thread minimal and
-scoped to what the feedback asks. If the project has tests or linters, run the
-relevant checks before folding changes into commits:
-
-```bash
-bundle exec rake default
-```
-
-Fix any failures before continuing.
-
-## Step 5: Fold each change into the matching commit
-
-Amend each change into its target commit — the existing commit on this branch
-that last touched the file — instead of adding new follow-up commits.
-
-1. Compute the base once:
-
-   ```bash
-   BASE=$(git merge-base origin/<base-branch> HEAD)
-   ```
-
-2. For each changed file, find its target commit (the topmost line is newest):
-
-   ```bash
-   git log --oneline "$BASE"..HEAD -- <path>
-   ```
-
-3. Stage that file and create a fixup commit aimed at its target SHA:
-
-   ```bash
-   git add <path>
-   git commit --fixup=<target-sha>
-   ```
-
-   Repeat for each changed file. When several files share the same target
-   commit, stage them together for one fixup.
-
-4. Autosquash the fixups into their targets non-interactively:
-
-   ```bash
-   GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash "$BASE"
-   ```
-
-5. Verify the result — the fixup commits should be gone and history should be
-   clean:
-
-   ```bash
-   git --no-pager log --oneline "$BASE"..HEAD
-   git status --short --branch
-   ```
-
-If a change does not correspond to any existing commit (e.g. a brand-new file
-requested in review), ask the user whether to fold it into a related commit or
-add a new, conventionally formatted commit.
-
-## Step 6: Force-push the branch
-
-History was rewritten, so the branch must be force-pushed. This is a
-history-rewriting operation — confirm with the user first, then use a lease to
-avoid clobbering unseen remote commits:
-
-```bash
-git push --force-with-lease
-```
-
-If the push is rejected, someone updated the remote branch. Fetch and reconcile
-before retrying; do not use `--force` to override the lease.
-
-## Step 7: Reply to and resolve threads
-
-For each thread that is now addressed:
-
-1. Reply to the thread, referencing what changed. Keep reply bodies shell-safe:
-   use single quotes for simple one-line replies, or assign a quoted heredoc to a
-   variable for arbitrary text. Do not put human-written reply text directly in a
-   double-quoted shell argument; review comments can contain characters such as
-   `!`, `$`, backticks, or quotes that the shell may expand before `gh` runs.
-
-```bash
-COMMENT_DATABASE_ID=COMMENT_DATABASE_ID_FROM_THREAD
-reply_body='Addressed in the latest push: <short summary>.'
-
-gh api \
-  "repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments/$COMMENT_DATABASE_ID/replies" \
-  -f body="$reply_body"
-```
-
-For multi-line replies or text that may contain shell metacharacters, use a
-single-quoted heredoc delimiter:
-
-```bash
-COMMENT_DATABASE_ID=COMMENT_DATABASE_ID_FROM_THREAD
-reply_body=$(cat <<'EOF'
-Addressed in the latest push: the guidance now covers `@!method` declarations.
-EOF
-)
-
-gh api \
-  "repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments/$COMMENT_DATABASE_ID/replies" \
-  -f body="$reply_body"
-```
-
-2. Resolve the thread:
-
-   ```bash
-   gh api graphql -f query='
-     mutation($threadId:ID!) {
-       resolveReviewThread(input:{threadId:$threadId}) {
-         thread { id isResolved }
-       }
-     }' -F threadId=THREAD_ID
-   ```
-
-Only resolve threads whose feedback was actually addressed (or that the user
-agreed to close after a reply). Leave threads open when the user still owes a
-decision.
-
-## Step 8: Request another Copilot review
-
-Request a fresh Copilot review on the PR so it re-reviews the amended commits.
-
-- Preferred: activate the pull request management tools, then request a Copilot
-  review via the GitHub pull request tooling (`request_copilot_review`).
-- Do **not** create a new Copilot PR task for a re-review; that opens separate
-  work instead of re-reviewing this PR.
-
-Finish by reporting to the user: the threads resolved, any threads left open and
-why, the new commit list, and the PR URL.
-
-## Troubleshooting
-
-| Issue | Solution |
-| ----- | -------- |
-| `git log "$BASE"..HEAD -- <path>` is empty | The file is new on this branch; ask the user whether to fold into a related commit or add a new commit. |
-| Rebase stops with conflicts | Resolve the conflict, `git add` the files, then `git rebase --continue`. |
-| Force-push rejected despite `--force-with-lease` | The remote branch moved; run `git fetch`, review the remote changes, reconcile, and retry. |
-| A thread has no obvious file/line (`path` is null) | It is a PR-level comment; reply at the PR level and resolve only if addressed. |
-| Unsure whether to push back on feedback | Stop and ask the user before replying or resolving. |