git 5.1.0 → 5.2.0

data/.github/workflows/experimental_continuous_integration.yml

@@ -1,59 +0,0 @@
-name: CI Experimental
-
-on:
-  push:
-    branches: [main]
-
-  workflow_dispatch:
-
-jobs:
-  build:
-    name: Ruby ${{ matrix.ruby }} on ${{ matrix.operating-system }}
-
-    # Skip this job if triggered by pushing a release commit
-    if: >-
-      github.event_name == 'workflow_dispatch' ||
-      (github.event_name == 'push' && !startsWith(github.event.head_commit.message, 'chore: release '))
-
-    runs-on: ${{ matrix.operating-system }}
-    continue-on-error: true
-    env: { JAVA_OPTS: -Djdk.io.File.enableADS=true }
-
-    strategy:
-      fail-fast: false
-      matrix:
-        include:
-          - # Building against head version of Ruby is considered experimental
-            ruby: head
-            operating-system: ubuntu-latest
-            experimental: Yes
-            java_version: ""
-
-          - # Since JRuby on Windows is known to not work, consider this experimental
-            ruby: jruby-head
-            operating-system: windows-latest
-            experimental: Yes
-            java_version: "21"
-
-    steps:
-      - name: Checkout Code
-        uses: actions/checkout@v6
-
-      - name: Setup Java
-        if: matrix.java_version != ''
-        uses: actions/setup-java@v5
-        with:
-          distribution: 'temurin'
-          java-version: ${{ matrix.java_version }}
-
-      - name: Setup Ruby
-        uses: ruby/setup-ruby@v1
-        with:
-          ruby-version: ${{ matrix.ruby }}
-          bundler-cache: true # runs 'bundle install' and caches installed gems automatically
-
-      - name: Run Build
-        run: bundle exec rake default
-
-      - name: Test Gem
-        run: bundle exec rake test:gem

data/.github/workflows/release.yml

@@ -1,52 +0,0 @@
----
-name: Release Gem
-
-description: |
-  This workflow creates a new release on GitHub and publishes the gem to
-  RubyGems.org.
-
-  The workflow uses the `googleapis/release-please-action` to handle the
-  release creation process and the `rubygems/release-gem` action to publish
-  the gem to rubygems.org
-
-on:
-  push:
-    branches: ["main", "4.x"]
-
-  workflow_dispatch:
-
-jobs:
-  release:
-    runs-on: ubuntu-latest
-
-    environment:
-      name: RubyGems
-      url: https://rubygems.org/gems/git
-
-    permissions:
-      contents: write
-      pull-requests: write
-      id-token: write
-
-    steps:
-      - name: Checkout project
-        uses: actions/checkout@v6
-
-      - name: Create release
-        uses: googleapis/release-please-action@v5
-        id: release
-        with:
-          token: ${{ secrets.AUTO_RELEASE_TOKEN }}
-          config-file: .release-please-config.json
-          manifest-file: .release-please-manifest.json
-
-      - name: Setup ruby
-        uses: ruby/setup-ruby@v1
-        if: ${{ steps.release.outputs.release_created }}
-        with:
-          bundler-cache: true
-          ruby-version: ruby
-
-      - name: Push to RubyGems.org
-        uses: rubygems/release-gem@v1
-        if: ${{ steps.release.outputs.release_created }}

data/.github/workflows/warm_bundler_caches.yml

@@ -1,82 +0,0 @@
-name: Warm Bundler Caches
-
-# GitHub Actions scopes every cache to the ref that wrote it, and only caches
-# written at *default-branch* scope are readable from other refs. The CI workflow runs
-# on `pull_request`, where github.ref is refs/pull/<n>/merge, so the caches it writes
-# are visible to that one PR and nothing else. The result is that nearly every PR paid
-# a cold `bundle install` on nearly every job. See issue #1674 for the measurements.
-#
-# This workflow exists solely to write those caches from refs/heads/main so that a
-# PR's *first* run can read them. It does no checkout-and-test work beyond what
-# `bundler-cache: true` needs: no specs, no RuboCop, no YARD.
-#
-# The matrix below must stay in sync with continuous_integration.yml: setup-ruby's
-# cache key embeds the runner OS, the resolved Ruby version, and the Gemfile.lock hash,
-# so a pair that is not warmed here still starts cold in CI. That includes the lint
-# job's Ruby 3.4 and the Windows 3.2 job, neither of which appears in CI's main matrix
-# list. The head rubies from experimental_continuous_integration.yml are deliberately
-# absent: that workflow already runs on `push: [main]` and warms its own caches.
-#
-# Only `main` is listed below. A run's readable caches are its own ref, its base ref,
-# and the default branch, so warming 4.x would need this file backported to the 4.x
-# branch with that branch's own matrix -- the copy on main is never what runs for a
-# push to 4.x.
-on:
-  push:
-    branches: [main]
-
-  workflow_dispatch:
-
-# Deliberately NOT cancel-in-progress. Two merges landing close together would
-# otherwise cancel the first one's warming mid-save, which is the opposite of the
-# point; queueing them costs a couple of runner-minutes and always leaves a warm cache
-# behind. This group is also distinct from CI's because github.workflow differs.
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: false
-
-permissions:
-  contents: read
-
-jobs:
-  warm:
-    name: Warm Ruby ${{ matrix.ruby }} on ${{ matrix.operating-system }}
-
-    runs-on: ${{ matrix.operating-system }}
-    timeout-minutes: 15
-
-    strategy:
-      fail-fast: false
-      matrix:
-        include:
-          - ruby: "3.2"
-            operating-system: ubuntu-latest
-
-          - # Hosts the lint and locale jobs in continuous_integration.yml
-            ruby: "3.4"
-            operating-system: ubuntu-latest
-
-          - ruby: "4.0"
-            operating-system: ubuntu-latest
-
-          - ruby: "truffleruby-24.2.1"
-            operating-system: ubuntu-latest
-
-          - ruby: "jruby-10.0.0.1"
-            operating-system: ubuntu-latest
-
-          - ruby: "3.2"
-            operating-system: windows-latest
-
-    steps:
-      - name: Checkout Code
-        uses: actions/checkout@v6
-
-      # No bundler-* inputs here on purpose. setup-ruby folds its `bundler`, `with`,
-      # `without`, and `only` inputs into the cache key, so any option set here and not
-      # in continuous_integration.yml would warm a key CI never looks up.
-      - name: Setup Ruby
-        uses: ruby/setup-ruby@v1
-        with:
-          ruby-version: ${{ matrix.ruby }}
-          bundler-cache: true # runs 'bundle install' and caches installed gems automatically

data/.gitignore

@@ -1,30 +0,0 @@
-*.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 failure tracking
-.rspec_status
-
-# generated git reference docs
-git-reference/
-
-# git versions built by bin/build-git-versions
-git-versions/
-
-tmp
-
-# per-developer Claude Code overrides (shared config is in .claude/settings.json)
-.claude/settings.local.json

data/.husky/commit-msg

@@ -1 +0,0 @@
-npx --no-install commitlint --edit "$1"

data/.husky/pre-commit

@@ -1,13 +0,0 @@
-#!/bin/sh
-
-branch=$(git branch --show-current)
-
-protected_branches="main 4.x"
-
-for protected in $protected_branches; do
-  if [ "$branch" = "$protected" ]; then
-    echo "ERROR: Direct commits to '$branch' are not allowed."
-    echo "       Create a topic branch first:  git switch -c <type>/<short-description>"
-    exit 1
-  fi
-done

data/.release-please-config.json

@@ -1,36 +0,0 @@
-{
-  "bootstrap-sha": "31374263eafea4e23352494ef4f6bea3ce62c1b5",
-  "packages": {
-    ".": {
-      "release-type": "ruby",
-      "package-name": "git",
-      "changelog-path": "CHANGELOG.md",
-      "version-file": "lib/git/version.rb",
-      "bump-minor-pre-major": true,
-      "bump-patch-for-minor-pre-major": true,
-      "draft": false,
-      "prerelease": false,
-      "include-component-in-tag": false,
-      "pull-request-title-pattern": "chore: release v${version}",
-      "changelog-sections": [
-        { "type": "feat",     "section": "Features",      "hidden": false },
-        { "type": "fix",      "section": "Bug Fixes",     "hidden": false },
-        { "type": "build",    "section": "Other Changes", "hidden": false },
-        { "type": "chore",    "section": "Other Changes", "hidden": false },
-        { "type": "ci",       "section": "Other Changes", "hidden": false },
-        { "type": "docs",     "section": "Other Changes", "hidden": false },
-        { "type": "perf",     "section": "Other Changes", "hidden": false },
-        { "type": "refactor", "section": "Other Changes", "hidden": false },
-        { "type": "revert",   "section": "Other Changes", "hidden": false },
-        { "type": "style",    "section": "Other Changes", "hidden": false },
-        { "type": "test",     "section": "Other Changes", "hidden": false }
-      ]
-    }
-  },
-  "plugins": [
-    {
-      "type": "sentence-case"
-    }
-  ],
-  "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json"
-}

data/.release-please-manifest.json

@@ -1,3 +0,0 @@
-{
-  ".": "5.1.0"
-}

data/.rspec

@@ -1,2 +0,0 @@
---require spec_helper
---color

data/.rubocop.yml

@@ -1,44 +0,0 @@
-inherit_from: .rubocop_todo.yml
-
-inherit_gem:
-  main_branch_shared_rubocop_config: config/rubocop.yml
-
-inherit_mode:
-  merge:
-    - Exclude
-
-# lib/git.rb is the gem's main entry-point module and is expected to be long
-Metrics/ModuleLength:
-  Exclude:
-    - "lib/git.rb"
-
-# gemspec and command DSL blocks are intentionally long
-Metrics/BlockLength:
-  Exclude:
-    - "*.gemspec"
-    - "lib/git/commands/**/*.rb"
-
-# Allow gemspec to have long lines
-Layout/LineLength:
-  Exclude:
-    - "*.gemspec"
-
-Style/OneClassPerFile:
-  Enabled: false
-
-# The repository is stored with LF line endings, but this cop defaults to `native`,
-# which expects CRLF on Windows and so reports every file in the project as an
-# offense there. Pinning it to `lf` makes the lint verdict identical on every
-# platform, which is the same reason CI runs RuboCop on one runtime only.
-Layout/EndOfLine:
-  EnforcedStyle: lf
-
-AllCops:
-  # Must match the floor of required_ruby_version in the gemspec: TargetRubyVersion
-  # decides which syntax RuboCop permits and suggests, so a value above the floor
-  # would let in code that does not parse on the oldest supported Ruby.
-  #
-  # Pinned explicitly rather than inferred because main_branch_shared_rubocop_config
-  # sets 3.1, which is older than this gem supports, and a value inherited through
-  # inherit_gem takes precedence over inference from the gemspec.
-  TargetRubyVersion: 3.2

data/.rubocop_todo.yml

@@ -1,30 +0,0 @@
-# This configuration was generated by
-# `rubocop --auto-gen-config --auto-gen-only-exclude --exclude-limit 999`
-# on 2026-01-28 20:48:52 UTC using RuboCop version 1.82.1.
-# The point is for the user to remove these configuration records
-# one by one as the offenses are removed from the code base.
-# Note that changes in the inspected code, or installation of new
-# versions of RuboCop, may require this file to be generated again.
-
-# Offense count: 1
-# This cop supports safe autocorrection (--autocorrect).
-# Configuration parameters: Max, AllowHeredoc, AllowURI, AllowQualifiedName, URISchemes, AllowRBSInlineAnnotation, AllowCopDirectives, AllowedPatterns, SplitStrings.
-# URISchemes: http, https
-Layout/LineLength:
-  Exclude:
-    - 'spec/unit/git/commands/tag/list_spec.rb'
-
-# Offense count: 4
-# Configuration parameters: CountComments, Max, CountAsOne.
-Metrics/ClassLength:
-  Exclude:
-    - 'lib/git/base.rb'
-    - 'lib/git/branch.rb'
-    - 'lib/git/commands/arguments.rb'
-    - 'lib/git/lib.rb'
-
-# Offense count: 1
-# Configuration parameters: CountComments, Max, CountAsOne, AllowedMethods, AllowedPatterns.
-Metrics/MethodLength:
-  Exclude:
-    - 'lib/git/commands/tag/list.rb'

data/.yard-lint.yml

@@ -1,75 +0,0 @@
-# Configuration for yard-lint (https://github.com/mensfeld/yard-lint)
-#
-# This config enforces the project's YARD documentation standards as described
-# in .github/skills/yard-documentation/SKILL.md. It replaces the retired
-# yardstick audit/coverage tooling.
-
-AllValidators:
-  # Lint private and protected objects too: the yard-documentation skill
-  # requires YARD docs on all objects, including Ruby-private methods.
-  YardOptions:
-    - --private
-    - --protected
-
-  Exclude:
-    - 'spec/**/*'
-    - 'vendor/**/*'
-
-  # Fail the run on any offense at convention severity or higher so that tag
-  # ordering, collection style, and other convention-level skill rules gate CI.
-  FailOnSeverity: convention
-
-  # Replaces the retired yardstick coverage threshold (was 75).
-  MinCoverage: 75.0
-
-# --- Overrides where yard-lint defaults conflict with the skill ---------------
-
-# The skill's templates end every doc block with a trailing blank comment line
-# (`#`) before the definition, so the default EmptyCommentLine validator would
-# flag the entire codebase. Disabled to preserve the project's house style.
-Documentation/EmptyCommentLine:
-  Enabled: false
-
-# The skill uses angle-bracket parametrized collection types
-# (e.g. `Array<String>`, `Hash<Symbol, String>`). This validator enforces the
-# `Hash{K => V}` form instead, which conflicts with the documented convention.
-Tags/CollectionType:
-  Enabled: false
-
-# Match the tag order documented in the skill's standard and overload templates.
-# Tags not listed here are left unordered (e.g. `overload`, `abstract`).
-Tags/Order:
-  Enabled: true
-  Severity: convention
-  EnforcedOrder:
-    - example
-    - param
-    - option
-    - return
-    - raise
-    - yield
-    - yieldparam
-    - yieldreturn
-    - note
-    - deprecated
-    - see
-    - api
-
-# --- Opt-in validators that enforce the skill's house style ------------------
-
-# The skill's templates put a blank comment line between the description and the
-# first tag and between every tag, so that the source formatter keeps each tag
-# visually separated. The built-in Tags/TagGroupSeparator can only separate
-# different tag *groups* (it can never split two sibling @param tags), so this
-# project uses Tags/TagSeparator, which requires a blank line between every
-# consecutive tag. @option is exempt so it can cluster directly beneath the
-# @param hash it documents.
-#
-# Tags/TagSeparator is not yet part of a released yard-lint; it is sourced from a
-# fork branch via the Gemfile until it is merged upstream and published.
-Tags/TagSeparator:
-  Enabled: true
-  Severity: convention
-  RequireAfterDescription: true
-  Exempt:
-    - option

data/CLAUDE.md

@@ -1,11 +0,0 @@
-# CLAUDE.md
-
-This file exists so Claude Code picks up the same project instructions as every
-other AI coding agent used in this repository.
-
-**Do not add project guidance here.** The canonical instructions live in
-[`.github/copilot-instructions.md`](.github/copilot-instructions.md) and are
-imported below. Edit that file so all agents stay in sync. Reserve this file for
-guidance that applies *only* to Claude Code.
-
-@.github/copilot-instructions.md

data/Gemfile

@@ -1,22 +0,0 @@
-# frozen_string_literal: true
-
-source 'https://rubygems.org'
-
-gemspec name: 'git'
-
-# Temporarily source yard-lint from a fork branch that adds the
-# Tags/TagSeparator validator (enabled in .yard-lint.yml). Revert to the
-# released gem once the validator is merged upstream and published.
-# See: https://github.com/mensfeld/yard-lint
-#
-# Pinned to a specific commit (rather than the branch name) so installs stay
-# deterministic while the branch continues to move. Bump this ref
-# intentionally: https://github.com/jcouball/yard-lint/tree/feature/tag-separator
-#
-# Scope this to the same runtimes as the gemspec's yard-lint dependency: it is
-# excluded on JRuby (RUBY_PLATFORM == 'java') and TruffleRuby, and requires
-# Ruby >= 3.3.
-if !(RUBY_PLATFORM == 'java' || RUBY_ENGINE == 'truffleruby') &&
-   Gem::Version.new(RUBY_VERSION) >= Gem::Version.new('3.3.0')
-  gem 'yard-lint', git: 'https://github.com/jcouball/yard-lint', ref: 'ef71742f2c88e2c296a20ab25fb4f25a4a384374'
-end

data/Rakefile

@@ -1,41 +0,0 @@
-# frozen_string_literal: true
-
-require 'rake/clean'
-
-# Load all .rake files from tasks and its subdirectories.
-Dir.glob('tasks/**/*.rake').each { |r| load r }
-
-default_tasks = %i[spec:unit spec:integration rubocop]
-default_tasks << :yard if Rake::Task.task_defined?(:yard)
-default_tasks << :build
-
-desc 'Run all CI tasks (tests, linters, yard, and build)'
-task default: default_tasks
-
-module Rake
-  # Overload Rake::Task to add logging
-  class Task
-    # Store the original execute method
-    alias original_execute execute
-
-    # Override execute to add a print statement
-    def execute(args = nil)
-      # Only output the task name if it wasn't the only top-level task
-      # rake default      # => output task name for each task called by the default task
-      # rake rubocop      # => do not output the task name
-      # rake rubocop yard # => output task name for rubocop and yard
-      top_level_tasks = Rake.application.top_level_tasks
-      box("rake #{name}") unless top_level_tasks.length == 1 && name == top_level_tasks[0]
-      original_execute(args)
-    end
-
-    private
-
-    def box(message)
-      width = message.length + 2
-      puts "┌#{'─' * width}┐"
-      puts "│ #{message} │"
-      puts "└#{'─' * width}┘"
-    end
-  end
-end

data/docker/test/Dockerfile

@@ -1,32 +0,0 @@
-FROM ruby
-
-WORKDIR /ruby-git
-
-
-ADD Gemfile git.gemspec ./
-ADD lib/git/version.rb ./lib/git/version.rb
-
-# `git.gemspec`'s `spec.files` shells out to `git ls-files`, which Bundler
-# evaluates below via the Gemfile's `gemspec` directive. Rather than relying
-# on the host's `.git` (which, for a build context copied from a linked git
-# worktree, is a file pointing at an absolute host path that doesn't exist
-# in the image — breaking every git command with "fatal: not a git
-# repository"), always initialize a throwaway repo scoped to the image. This
-# also keeps the image self-contained and avoids ever copying the
-# (potentially large) host `.git` directory in (see `.dockerignore`). A
-# second commit is added below once the full source tree is present, so the
-# final file list is complete.
-RUN git init -q && \
-    git -c user.email=docker@example.com -c user.name=docker add -A && \
-    git -c user.email=docker@example.com -c user.name=docker commit -q -m 'Throwaway repo for Docker test run'
-
-RUN bundle install
-
-ADD . .
-
-# Refresh the throwaway repo now that the full source tree is present, so
-# `git ls-files` reflects every file for `rake build`'s `spec.files`.
-RUN git -c user.email=docker@example.com -c user.name=docker add -A && \
-    git -c user.email=docker@example.com -c user.name=docker commit -q -m 'Add full source' --allow-empty
-
-ENTRYPOINT ["bundle", "exec", "rake", "default"]

data/package.json

@@ -1,10 +0,0 @@
-{
-  "devDependencies": {
-    "@commitlint/cli": "^19.8.0",
-    "@commitlint/config-conventional": "^19.8.0",
-    "husky": "^9.1.7"
-  },
-  "scripts": {
-    "prepare": "husky"
-  }
-}

data/redesign/1_architecture_existing.md

@@ -1,102 +0,0 @@
-# Analysis of the Current Git Gem Architecture and Its Challenges
-
-This document provides an in-depth look at the current architecture of the `git` gem,
-outlining its primary components and the design challenges that have emerged over
-time. Understanding these challenges is the key motivation for the proposed
-architectural redesign.
-
-- [1. Overview of the Current Architecture](#1-overview-of-the-current-architecture)
-- [2. Key Architectural Challenges](#2-key-architectural-challenges)
-  - [A. Unclear Separation of Concerns](#a-unclear-separation-of-concerns)
-  - [B. Circular Dependency](#b-circular-dependency)
-  - [C. Undefined Public API Boundary](#c-undefined-public-api-boundary)
-  - [D. Slow and Brittle Test Suite](#d-slow-and-brittle-test-suite)
-
-## 1. Overview of the Current Architecture
-
-The gem's current design is centered around three main classes: `Git`, `Git::Base`,
-and `Git::Lib`.
-
-- **`Git` (Top-Level Module)**: This module serves as the primary public entry point
-  for creating repository objects. It contains class-level factory methods like
-  `Git.open`, `Git.clone`, and `Git.init`. It also provides an interface for
-  accessing global git configuration settings.
-
-- **`Git::Base`**: This is the main object that users interact with after creating or
-  opening a repository. It holds the high-level public API for most git operations
-  (e.g., `g.commit`, `g.add`, `g.status`). It is responsible for managing the
-  repository's state, such as the paths to the working directory and the `.git`
-  directory.
-
-- **`Git::Lib`**: This class is intended to be the low-level wrapper around the `git`
-  command-line tool. It contains the methods that build the specific command-line
-  arguments and execute the `git` binary. In practice, it also contains a significant
-  amount of logic for parsing the output of these commands.
-
-## 2. Key Architectural Challenges
-
-While this structure has been functional, several significant design challenges make
-the codebase difficult to maintain, test, and evolve.
-
-### A. Unclear Separation of Concerns
-
-The responsibilities between Git::Base and Git::Lib are "muddy" and overlap
-significantly.
-
-- `Git::Base` sometimes contains logic that feels like it should be lower-level.
-
-- `Git::Lib`, which should ideally only be concerned with command execution, is
-  filled with high-level logic for parsing command output into specific Ruby objects
-  (e.g., parsing log output, diff stats, and branch lists).
-
-This blending of responsibilities makes it hard to determine where a specific piece
-of logic should reside, leading to an inconsistent and confusing internal structure.
-
-### B. Circular Dependency
-
-This is the most critical architectural flaw in the current design.
-
-- A `Git::Base` instance is created.
-
-- The first time a command is run, `Git::Base` lazily initializes a `Git::Lib`
-  instance via its `.lib` accessor method.
-
-- The `Git::Lib` constructor is passed the `Git::Base` instance (`self`) so that it
-  can read the repository's path configuration back from the object that is creating
-  it.
-
-This creates a tight, circular coupling: `Git::Base` depends on `Git::Lib` to execute
-commands, but `Git::Lib` depends on `Git::Base` for its own configuration. This
-pattern makes the classes difficult to instantiate or test in isolation and creates a
-fragile system where changes in one class can have unexpected side effects in the
-other.
-
-### C. Undefined Public API Boundary
-
-The gem lacks a formally defined public interface. Because `Git::Base` exposes its
-internal `Git::Lib` instance via the public `g.lib` accessor, many users have come to
-rely on `Git::Lib` and its methods as if they were part of the public API.
-
-This has two negative consequences:
-
-1. It prevents the gem's maintainers from refactoring or changing the internal
-   implementation of `Git::Lib` without causing breaking changes for users.
-
-2. It exposes complex, internal methods to users, creating a confusing and
-   inconsistent user experience.
-
-### D. Slow and Brittle Test Suite
-
-The current testing strategy, built on `TestUnit`, suffers from two major issues:
-
-- **Over-reliance on Fixtures**: Most tests depend on having a complete, physical git
-  repository on the filesystem to run against. Managing these fixtures is cumbersome.
-
-- **Excessive Shelling Out**: Because the logic for command execution and output
-  parsing are tightly coupled, nearly every test must shell out to the actual `git`
-  command-line tool.
-
-This makes the test suite extremely slow, especially on non-UNIX platforms like
-Windows where process creation is more expensive. The slow feedback loop discourages
-frequent testing and makes development more difficult. The brittleness of
-filesystem-dependent tests also leads to flickering or unreliable test runs.