git 5.1.0 → 5.3.0

data/.claude/settings.json

@@ -1,16 +0,0 @@
-{
-  "$schema": "https://json.schemastore.org/claude-code-settings.json",
-  "hooks": {
-    "SessionStart": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "\"$CLAUDE_PROJECT_DIR/.github/hooks/run-bin-setup-once.sh\"",
-            "timeout": 900
-          }
-        ]
-      }
-    ]
-  }
-}

data/.claude/skills

@@ -1 +0,0 @@
-../.github/skills

data/.commitlintrc.yml

@@ -1,38 +0,0 @@
----
-extends: '@commitlint/config-conventional'
-
-rules:
-  # See: https://commitlint.js.org/reference/rules.html
-  #
-  # Rules are made up by a name and a configuration array. The configuration
-  # array contains:
-  #
-  # * Severity [0..2]: 0 disable rule, 1 warning if violated, or 2 error if
-  #   violated
-  # * Applicability [always|never]: never inverts the rule
-  # * Value: value to use for this rule (if applicable)
-  #
-  # Run `npx commitlint --print-config` to see the current setting for all
-  # rules.
-  #
-  header-max-length:      [2, always, 100]        # Header can not exceed 100 chars
-
-  type-case:              [2, always, lower-case] # Type must be lower case
-  type-empty:             [2, never]              # Type must not be empty
-
-  # Supported conventional commit types
-  type-enum:              [2, always, [build, ci, chore, docs, feat, fix, perf, refactor, revert, style, test]]
-
-  scope-case:             [2, always, lower-case] # Scope must be lower case
-
-  # Error if subject is one of these cases (encourages lower-case)
-  subject-case:           [2, never, [sentence-case, start-case, pascal-case, upper-case]]
-  subject-empty:          [2, never]              # Subject must not be empty
-  subject-full-stop:      [2, never, "."]         # Subject must not end with a period
-
-  body-leading-blank:     [2, always]             # Body must have a blank line before it
-  body-max-line-length:   [2, always, 100]        # Body lines can not exceed 100 chars
-
-  footer-leading-blank:   [2, always]             # Footer must have a blank line before it
-  footer-max-line-length: [2, always, 100]        # Footer lines can not exceed 100 chars
-  

data/.dockerignore

@@ -1,27 +0,0 @@
-# Keep the Docker build context free of host-generated artifacts so the
-# image always builds gems fresh instead of picking up stale or
-# host-specific state (see .gitignore for the equivalent git-tracked list).
-#
-# .git is also excluded: the Dockerfile initializes its own throwaway git
-# repo instead of relying on the host's, since the host's `.git` may be a
-# linked-worktree pointer file referencing a path that doesn't exist in the
-# image (see docker/test/Dockerfile for details).
-.git
-*.gem
-*.kpf
-*.sw?
-.DS_Store
-.bundle/
-vendor/bundle/
-coverage
-doc
-.yardoc
-pkg
-rdoc
-Gemfile.lock
-node_modules
-package-lock.json
-ai-prompt.erb
-rubocop-report.json
-.rspec_status
-git-reference/

data/.github/copilot-instructions.md

@@ -1,30 +0,0 @@
-# GitHub Copilot Instructions for ruby-git
-
-## Project Overview
-
-A Ruby gem providing an interface to Git repositories by wrapping system calls to the
-`git` CLI.
-
-Read the "Project Context" skill (`.github/skills/project-context/SKILL.md`) for
-design philosophy, technical details, and compatibility requirements.
-
-This project enforces Conventional Commits. See `.commitlintrc.yml` for allowed types
-and scopes. Never use `#` in the commit message body. Doing so will cause
-commitlint to incorrectly parse the commit message body as a footer. If you need to
-refer to an issue in the body, use `issue 999` instead of `issue #999`. It is still
-fine to use `#` in footer values such as `Closes: #999` or `Refs: #999`.
-
-## Terminology & Writing Style
-
-- Use American English.
-- **Version strings:** Use `vN.x` for major series compatibility (e.g., `v4.x`) and
-  `vN.0.0` for specific releases (e.g., `v5.0.0`). Never use the ambiguous `vN.0`.
-- **RuboCop:** Use `RuboCop` for prose and `rubocop` for CLI or gem names. Never use
-  `Rubocop`.
-
-## Branch & PR Strategy
-
-| Target | When |
-| --- | --- |
-| `main` | New features, breaking changes, all active development |
-| `4.x` | Security fixes and backward-compatible bug fixes for the v4.x series |

data/.github/hooks/bin-setup-on-worktree.json

@@ -1,11 +0,0 @@
-{
-  "hooks": {
-    "SessionStart": [
-      {
-        "type": "command",
-        "command": ".github/hooks/run-bin-setup-once.sh",
-        "timeout": 900
-      }
-    ]
-  }
-}

data/.github/hooks/run-bin-setup-once.sh

@@ -1,20 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-# This hook is shared by every agent configured for this repo (GitHub Copilot via
-# .github/hooks/, Claude Code via .claude/settings.json), so do not assume the
-# caller's working directory.
-command -v git >/dev/null 2>&1 || exit 0
-cd "$(dirname "${BASH_SOURCE[0]}")/../.." || exit 0
-
-# Skip if this repo does not use bin/setup.
-[[ -x "./bin/setup" ]] || exit 0
-
-# Keep setup idempotent per-worktree. The marker is shared across agents so that
-# cloning and opening the repo in two different tools does not run setup twice.
-marker="$(git rev-parse --git-path agent-bin-setup.done 2>/dev/null)" || exit 0
-[[ -f "$marker" ]] && exit 0
-
-./bin/setup
-mkdir -p "$(dirname "$marker")"
-touch "$marker"

data/.github/issue_template.md

@@ -1,15 +0,0 @@
-### Subject of the issue
-Describe your issue here.
-
-### Your environment
-* version of git and ruby-git
-* version of ruby
-
-### Steps to reproduce
-Tell us how to reproduce this issue. 
-
-### Expected behaviour
-What did you expect to happen?
-
-### Actual behaviour
-What actually happened?

data/.github/prompts/iteratively-address-copilot-reviews.prompt.md

@@ -1,188 +0,0 @@
----
-agent: agent
-model: claude-sonnet-4.6
-description: Address all unresolved Copilot review threads on the active pull request until there are no remaining unresolved review threads
----
-
-Address unresolved **Copilot** review threads on the active pull request. Ignore threads opened by human reviewers. Ask me for clarification or decisions as needed.
-
-If any terminal script command fails, stop immediately. Do not continue the loop, do not resolve additional threads, and do not request a new review. Report: the failed command, exit code, and the most relevant stderr output. **Exception**: the reply POST in Step 3 is intentionally non-fatal — a 404 after a force-push is expected and the resolve step must still run.
-
-## Terminology
-
-- **Review** — a top-level review submission by `copilot-pull-request-reviewer`, with a `submittedAt` timestamp and an optional summary body. A single review may contain zero or more Review Threads.
-- **Review Thread** — an inline comment thread attached to a specific code location. Key fields: `id` (GraphQL node ID, e.g. `PRRT_…`), `isResolved` (manually resolved by a maintainer), `isOutdated` (the underlying code changed since the thread was created). Each thread has one or more comments; the first comment is Copilot's suggestion.
-- **Check Run** — a standard CI status object on the HEAD commit. Note: Copilot Reviews do **not** create a Check Run; use the Reviews API to detect completion instead.
-
-## Before the Loop
-
-Run in terminal to establish `OWNER`, `REPO`, and `PR_NUMBER` for use throughout:
-
-```bash
-set -euo pipefail
-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')
-: "${OWNER:?failed to resolve OWNER}"
-: "${REPO:?failed to resolve REPO}"
-: "${PR_NUMBER:?failed to resolve PR_NUMBER}"
-```
-
-Fetch unresolved, non-outdated Copilot Review Threads:
-
-```bash
-set -euo pipefail
-: "${OWNER:?missing OWNER}"
-: "${REPO:?missing REPO}"
-: "${PR_NUMBER:?missing PR_NUMBER}"
-threads_json=$(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
-          comments(first:1){nodes{databaseId author{login} createdAt body}}}}}}
-  }' -f owner="$OWNER" -f repo="$REPO" -F pr="$PR_NUMBER" \
-  --jq '.data.repository.pullRequest.reviewThreads.nodes')
-if [[ $(echo "$threads_json" | jq 'length') -ge 100 ]]; then
-  echo "Error: the PR already has 100 threads or more. Aborting."
-  exit 1
-fi
-echo "$threads_json" | jq '[.[] |
-  select(.isResolved==false) |
-  select(.isOutdated==false) |
-  select(.comments.nodes[0].author.login=="copilot-pull-request-reviewer")]'
-```
-
-- **Results non-empty** → proceed directly to the iteration loop.
-- **Results empty** → record `REVIEW_REQUESTED_AT` (current UTC, `YYYY-MM-DDTHH:MM:SSZ`, e.g. `2026-06-16T12:00:00Z`), request a new Copilot Review using the `mcp_github_mcp_se_request_copilot_review` tool (owner, repo, pullNumber), then jump to the **Wait for Review** section below.
-
-## Iteration Loop
-
-Repeat up to **${input:maxIterations:5}** iterations:
-
-### 1. Address threads
-
-Re-fetch unresolved, non-outdated Copilot Review Threads using the same `gh api graphql` query from Before the Loop. Group by file. For each file, read it once and address all its threads in that single pass:
-- Validate each suggestion before accepting it.
-- If a suggestion is invalid or out of scope: reply explaining why, then resolve the thread without changing code.
-- Otherwise: implement the change using TDD where possible; ensure test coverage.
-
-Skip any thread where `isOutdated` is true — the code it references has already changed; Copilot will re-evaluate it in the next Review.
-
-After all threads are addressed, run `rake`. If it fails, capture `rake 2>&1 | tail -n 50` and fix the failure before continuing.
-
-### 2. Commit and push
-
-Amend each change into the most relevant existing commit on the branch based on file name. If a change spans multiple commits or doesn't map clearly to one, ask me which commit to amend into (or whether to create a new commit). Confirm the working tree is clean and `rake` passes, then force push.
-
-### 3. Reply and resolve
-
-For each addressed thread object from the unresolved-threads query, in the same `run_in_terminal` script block that performs reply/resolve, export:
-
-- `COMMENT_DBID=.comments.nodes[0].databaseId`
-- `THREAD_ID=.id`
-- `EXPLANATION` to your plain-language fix summary for that thread
-
-Set the per-thread variables (`COMMENT_DBID`, `THREAD_ID`, `EXPLANATION`) immediately before running the commands below — do not rely on them surviving from a prior terminal invocation.
-
-Then post a reply and resolve it:
-
-```bash
-set -euo pipefail
-: "${OWNER:?missing OWNER}"
-: "${REPO:?missing REPO}"
-: "${COMMENT_DBID:?missing COMMENT_DBID}"
-: "${EXPLANATION:?missing EXPLANATION}"
-
-# Reply (COMMENT_DBID = databaseId of the thread's first comment)
-# Build JSON via jq to safely handle quotes/newlines/special chars in EXPLANATION.
-# EXPLANATION should contain the full reply text (e.g. "Fixed: ..." or "Not addressing this because...").
-BODY_JSON=$(jq -n --arg body "$EXPLANATION" '{body:$body}')
-# Non-fatal: a force-push can mark threads as outdated, causing the REST reply to return 404.
-# Always continue to the GraphQL resolve step regardless.
-gh api "repos/$OWNER/$REPO/pulls/comments/$COMMENT_DBID/replies" \
-  -X POST --input - <<<"$BODY_JSON" \
-  || echo "Warning: reply POST failed (thread may be outdated after force-push) — skipping reply, will still resolve"
-
-: "${THREAD_ID:?missing THREAD_ID}"
-
-# Resolve (THREAD_ID = GraphQL node id, e.g. PRRT_...)
-gh api graphql \
-  -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' \
-  -f id="$THREAD_ID"
-```
-
-### 4. Request review
-
-**If this was the ${input:maxIterations:5}th iteration**, skip steps 4 and 6 entirely — go directly to step 5 (Report) and then produce the Final Report.
-
-Otherwise, capture `REVIEW_REQUESTED_AT` by running `date -u +%Y-%m-%dT%H:%M:%SZ` in the terminal immediately before requesting the review. Then request a new Copilot Review using the `mcp_github_mcp_se_request_copilot_review` tool (owner, repo, pullNumber).
-
-### 5. Report
-
-List what was addressed and how each issue was resolved.
-
-### 6. Wait
-
-Jump to the **Wait for Review** section below. Return here to begin the next iteration once the new Copilot Review has been submitted.
-
-## Wait for Review
-
-**[BLOCKING — do not proceed until complete]** Poll for a new Copilot Review submission using the Reviews API. A Review with `submittedAt >= REVIEW_REQUESTED_AT` is the authoritative completion signal — it fires even when Copilot produces zero Review Threads.
-
-Run the following script via `run_in_terminal` (sync mode, timeout 750000 ms). Set the four variables on the first line to their actual values. On success, capture the script's last output line; on failure, follow the global failure-reporting rule (failed command, exit code, relevant stderr):
-
-```bash
-set -euo pipefail
-# Replace with actual values. REVIEW_REQUESTED_AT = output of `date -u +%Y-%m-%dT%H:%M:%SZ` captured just before requesting the review.
-OWNER="ruby-git"; REPO="ruby-git"; PR_NUMBER="1439"; REVIEW_REQUESTED_AT="2026-06-16T12:00:00Z"
-: "${OWNER:?missing OWNER}"
-: "${REPO:?missing REPO}"
-: "${PR_NUMBER:?missing PR_NUMBER}"
-: "${REVIEW_REQUESTED_AT:?missing REVIEW_REQUESTED_AT}"
-START=$(date +%s)
-for i in $(seq 1 60); do
-  new_review=$(gh pr view "$PR_NUMBER" --repo "$OWNER/$REPO" --json reviews \
-    --jq "[.reviews[] | select(.author.login==\"copilot-pull-request-reviewer\") | select(.submittedAt != null) | select(.submittedAt | fromdateiso8601 >= (\"$REVIEW_REQUESTED_AT\" | fromdateiso8601))] | length") \
-    || { rc=$?; echo "Error: gh pr view failed (exit $rc)"; exit $rc; }
-  if [[ -n "$new_review" && "$new_review" -gt 0 ]]; then
-    raw_nodes=$(gh api graphql -f query='
-      query($owner:String!,$repo:String!,$pr:Int!){
-        repository(owner:$owner,name:$repo){
-          pullRequest(number:$pr){
-            reviewThreads(first:100){nodes{isResolved isOutdated comments(first:1){nodes{author{login}}}}}
-          }
-        }
-      }' -f owner="$OWNER" -f repo="$REPO" -F pr="$PR_NUMBER" \
-      --jq '.data.repository.pullRequest.reviewThreads.nodes') \
-      || { rc=$?; echo "Error: gh api graphql failed (exit $rc)"; exit $rc; }
-    if [[ $(echo "$raw_nodes" | jq 'length') -ge 100 ]]; then
-      echo "Error: the PR already has 100 threads or more. Aborting."
-      exit 1
-    fi
-    count=$(echo "$raw_nodes" | jq "[.[] |
-      select(.isResolved==false) |
-      select(.isOutdated==false) |
-      select(.comments.nodes[0].author.login==\"copilot-pull-request-reviewer\")] | length")
-    echo "done: $count threads"  # count of all unresolved non-outdated Copilot Review Threads
-    exit 0
-  fi
-  elapsed=$(( $(date +%s) - START ))
-  echo "Waiting for Copilot Review to complete... (${elapsed}s elapsed)"
-  sleep 10
-done
-echo "timed out after 60 polls"
-exit 1
-```
-
-**If `timed out after 60 polls`**: stop immediately and ask me whether to re-request the review and retry, or abort.
-
-**If `done: 0 threads`**: the loop is complete — exit.
-
-**If `done: N threads`** (N > 0): begin the next iteration.
-
-## Final Report
-
-- Total iterations completed
-- Total threads addressed
-- Unresolved threads in the final Copilot review (should be 0 if the loop exited cleanly)

data/.github/pull_request_template.md

@@ -1,21 +0,0 @@
-Review our [guidelines for contributing](https://github.com/ruby-git/ruby-git/blob/main/CONTRIBUTING.md) to this repository. A good start is to:
-
-- Write tests for your changes
-- Run `rake` before pushing
-- Include / update docs in the README.md and in YARD documentation
-
-# Description
-
-\<your description here\>
-
-## Checklist
-
-- [ ] I reviewed and applied the project's [AI Policy](../AI_POLICY.md). I understand
-  and verify any AI-assisted changes included in this PR and ensured they meet
-  quality, security, and licensing standards.
-- [ ] I ran `bundle exec rake` locally on this branch and it passed (see
-  [Local development setup](../CONTRIBUTING.md#local-development-setup)).
-- [ ] Tests added/updated as needed.
-- [ ] `bundle exec rake spec:unit` reports 100% line and branch coverage (see
-  [Test coverage policy](../CONTRIBUTING.md#test-coverage-policy)).
-- [ ] Documentation updated where applicable (README and/or YARD).

data/.github/skills/breaking-change-analysis/SKILL.md

@@ -1,99 +0,0 @@
----
-name: breaking-change-analysis
-description: "Assesses the impact of API changes before implementation to understand what code would break and plan appropriate migration paths. Use when removing methods, changing interfaces, or planning deprecations."
----
-
-# Breaking Change Analysis Workflow
-
-Assess the impact of API changes before implementation. Use when removing methods,
-changing method signatures, altering return types/values, changing exception types,
-or modifying default behavior.
-
-## Contents
-
-- [How to use this skill](#how-to-use-this-skill)
-- [Related skills](#related-skills)
-- [Step 1: Identify the Change Scope](#step-1-identify-the-change-scope)
-- [Step 2: Find All Usages](#step-2-find-all-usages)
-- [Step 3: Assess and Document Impact](#step-3-assess-and-document-impact)
-- [Step 4: Plan Migration Path](#step-4-plan-migration-path)
-
-## How to use this skill
-
-Attach this file to your Copilot Chat context, then invoke it with the specific
-API/method change you are considering. Use this workflow before coding to assess
-impact and plan migration.
-
-## Related skills
-
-- [Development Workflow](../development-workflow/SKILL.md) — implement required
-   changes using strict TDD
-
-## Step 1: Identify the Change Scope
-
-1. Determine which classes and methods are affected.
-2. Check API visibility (`@api public` vs `@api private` in YARD docs).
-3. Check if the change affects `Git::Repository` (the current facade layer, modules under `lib/git/repository/`).
-
-## Step 2: Find All Usages
-
-1. **Internal usages:**
-
-   ```bash
-   grep -rn "method_name" lib/ spec/
-   ```
-
-2. **External usage (if applicable):**
-
-   ```bash
-   gh search code "Git::Repository#method_name language:ruby"
-   ```
-
-## Step 3: Assess and Document Impact
-
-Produce an impact assessment:
-
-```markdown
-## Breaking Change Impact Assessment
-
-### Change Description
-[What is being changed]
-
-### Affected API
-- Class: `Git::SomeClass`
-- Method: `#some_method`
-- Current signature: `def some_method(arg, opts = {})`
-- Proposed signature: `def some_method(arg, force: false)`
-
-### Internal Impact
-- Files affected: X
-- Tests to update: Y
-
-### External Impact
-- Severity: [High/Medium/Low]
-- Migration difficulty: [Easy/Medium/Hard]
-
-### Migration Path
-[How users should update their code]
-```
-
-## Step 4: Plan Migration Path
-
-**Project versioning policy:**
-- Breaking changes are batched for major releases
-- Use deprecation warnings in the current major series before removal in the next major release
-
-**Deprecation approach:**
-
-```ruby
-# @deprecated Use {#new_method} instead. Will be removed in the next major release.
-def old_method(*args)
-  warn "[DEPRECATION] `old_method` is deprecated. Use `new_method` instead."
-  new_method(*args)
-end
-```
-
-**Documentation requirements:**
-- Add `@deprecated` YARD tag with migration guidance
-- Mark commits with `!` for breaking changes and include `BREAKING CHANGE:` footer
-- DO NOT update CHANGELOG.md — it is auto-generated from commit messages