git 1.19.1 → 4.4.5

data/redesign/1_architecture_existing.md

@@ -0,0 +1,66 @@
+# 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 difficula 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.

data/redesign/2_architecture_redesign.md

@@ -0,0 +1,130 @@
+# Proposed Redesigned Architecture for the Git Gem
+
+This document outlines a proposal for a major redesign of the git gem, targeted for version 5.0.0. The goal of this redesign is to modernize the gem's architecture, making it more robust, maintainable, testable, and easier for new contributors to understand.
+
+- [1. Motivation](#1-motivation)
+- [2. The New Architecture: A Three-Layered Approach](#2-the-new-architecture-a-three-layered-approach)
+- [3. Key Design Principles](#3-key-design-principles)
+  - [A. Clear Public vs. Private API](#a-clear-public-vs-private-api)
+  - [B. Dependency Injection](#b-dependency-injection)
+  - [C. Immutable Return Values](#c-immutable-return-values)
+  - [D. Clear Naming for Path Objects](#d-clear-naming-for-path-objects)
+- [4. Testing Strategy Overhaul](#4-testing-strategy-overhaul)
+- [5. Impact on Users: Breaking Changes for v5.0.0](#5-impact-on-users-breaking-changes-for-v500)
+
+## 1. Motivation
+
+The current architecture, while functional, has several design issues that have accrued over time, making it difficult to extend and maintain.
+
+- **Unclear Separation of Concerns**: The responsibilities of the `Git`, `Git::Base`, and `Git::Lib` classes are "muddy." `Git::Base` acts as both a high-level API and a factory, while `Git::Lib` contains a mix of low-level command execution and high-level output parsing.
+
+- **Circular Dependency**: A key architectural flaw is the circular dependency between `Git::Base` and `Git::Lib`. `Git::Base` creates and depends on `Git::Lib`, but `Git::Lib`'s constructor requires an instance of Git::Base to access configuration. This tight coupling makes the classes difficult to reason about and test in isolation.
+
+- **Undefined Public API**: The boundary between the gem's public API and its internal implementation is not clearly defined. This has led some users to rely on internal classes like `Git::Lib`, making it difficult to refactor the internals without introducing breaking changes.
+
+- **Slow and Brittle Test Suite**: The current tests rely heavily on filesystem fixtures and shelling out to the git command line for almost every test case. This makes the test suite slow and difficult to maintain, especially on non-UNIX platforms.
+
+## 2. The New Architecture: A Three-Layered Approach
+
+The new design is built on a clear separation of concerns, dividing responsibilities into three distinct layers: a Facade, an Execution Context, and Command Objects.
+
+1. The Facade Layer: Git::Repository
+
+    This is the primary public interface that users will interact with.
+
+    **Renaming**: `Git::Base` will be renamed to `Git::Repository`. This name is more descriptive and intuitive.
+
+    **Responsibility**: It will serve as a clean, high-level facade for all common git operations. Its methods will be simple, one-line calls that delegate the actual work to an appropriate command object.
+
+    **Scalability**: To prevent this class from growing too large, its methods will be organized into logical modules (e.g., `Git::Repository::Branching`, `Git::Repository::History`) which are then included in the main class. This keeps the core class definition small and the features well-organized. These categories will be inspired by (but not slavishly follow) the git command line reference in [this page](https://git-scm.com/docs).
+
+2. The Execution Layer: Git::ExecutionContext
+
+    This is the low-level, private engine for running commands.
+
+    **Renaming**: `Git::Lib` will be renamed to `Git::ExecutionContext`.
+
+    **Responsibility**: Its sole purpose is to execute raw git commands. It will manage the repository's environment (working directory, .git path, logger) and use the existing `Git::CommandLine` class to interact with the system's git binary. It will have no knowledge of any specific git command's arguments or output.
+
+3. The Logic Layer: Git::Commands
+
+    This is where all the command-specific implementation details will live.
+
+    **New Classes**: For each git operation, a new command class will be created within the `Git::Commands` namespace (e.g., `Git::Commands::Commit`, `Git::Commands::Diff`).
+
+    **Dual Responsibility**: Each command class will be responsible for:
+
+    1. **Building Arguments**: Translating high-level Ruby options into the specific command-line flags and arguments that git expects.
+
+    2. **Parsing Output**: Taking the raw string output from the ExecutionContext and converting it into rich, structured Ruby objects.
+
+    **Handling Complexity**: For commands with multiple behaviors (like git diff), we can use specialized subclasses (e.g., Git::Commands::Diff::NameStatus, Git::Commands::Diff::Stats) to keep each class focused on a single responsibility.
+
+## 3. Key Design Principles
+
+The new architecture will be guided by the following modern design principles.
+
+### A. Clear Public vs. Private API
+
+A primary goal of this redesign is to establish a crisp boundary between the public API and internal implementation details.
+
+- **Public Interface**: The public API will consist of the `Git` module (for factories), the `Git::Repository` class, and the specialized data/query objects it returns (e.g., `Git::Log`, `Git::Status`, `Git::Object::Commit`).
+
+- **Private Implementation**: All other components, including `Git::ExecutionContext` and all classes within the `Git::Commands` namespace, will be considered internal. They will be explicitly marked with the `@api private` YARD tag to discourage external use.
+
+### B. Dependency Injection
+
+The circular dependency will be resolved by implementing a clear, one-way dependency flow.
+
+1. The factory methods (`Git.open`, `Git.clone`) will create and configure an instance of `Git::ExecutionContext`.
+
+2. This `ExecutionContext` instance will then be injected into the constructor of the `Git::Repository` object.
+
+This decouples the `Repository` from its execution environment, making the system more modular and easier to test.
+
+### C. Immutable Return Values
+
+To create a more predictable and robust API, methods will return structured, immutable data objects instead of raw strings or hashes.
+
+This will be implemented using `Data.define` or simple, frozen `Struct`s.
+
+For example, instead of returning a raw string, `repo.config('user.name')` will return a `Git::Config::Value` object containing the key, value, scope, and source path.
+
+### D. Clear Naming for Path Objects
+
+To improve clarity, all classes that represent filesystem paths will be renamed to follow a consistent `...Path` suffix convention.
+
+- `Git::WorkingDirectory` -> `Git::WorkingTreePath`
+
+- `Git::Index` -> `Git::IndexPath`
+
+- The old `Git::Repository` (representing the .git directory/file) -> `Git::RepositoryPath`
+
+## 4. Testing Strategy Overhaul
+
+The test suite will be modernized to be faster, more reliable, and easier to work with.
+
+- **Migration to RSpec**: The entire test suite will be migrated from TestUnit to RSpec to leverage its modern tooling and expressive DSL.
+
+- **Layered Testing**: A three-layered testing strategy will be adopted:
+
+  1. **Unit Tests**: The majority of tests will be fast, isolated unit tests for the `Command` classes, using mock `ExecutionContexts`.
+
+  2. **Integration Tests**: A small number of integration tests will verify that `ExecutionContext` correctly interacts with the system's `git` binary.
+
+  3. **Feature Tests**: A minimal set of high-level tests will ensure the public facade on `Git::Repository` works end-to-end.
+
+- **Reduced Filesystem Dependency**: This new structure will dramatically reduce the suite's reliance on slow and brittle filesystem fixtures.
+
+## 5. Impact on Users: Breaking Changes for v5.0.0
+
+This redesign is a significant undertaking and will be released as version 5.0.0. It includes several breaking changes that users will need to be aware of when upgrading.
+
+- **`Git::Lib` is Removed**: Any code directly referencing `Git::Lib` will break.
+
+- **g.lib Accessor is Removed**: The `.lib` accessor on repository objects will be removed.
+
+- **Internal Methods Relocated**: Methods that were previously accessible via g.lib will now be private implementation details of the new command classes and will not be directly reachable.
+
+Users should only rely on the newly defined public interface.
+

data/redesign/3_architecture_implementation.md

@@ -0,0 +1,138 @@
+# Implementation Plan for Git Gem Redesign (v5.0.0)
+
+This document outlines a step-by-step plan to implement the proposed architectural redesign. The plan is structured to be incremental, ensuring that the gem remains functional and passes its test suite after each major step. This approach minimizes risk and allows for a gradual, controlled migration to the new architecture.
+
+- [Phase 1: Foundation and Scaffolding](#phase-1-foundation-and-scaffolding)
+- [Phase 2: The Strangler Fig Pattern - Migrating Commands](#phase-2-the-strangler-fig-pattern---migrating-commands)
+- [Phase 3: Refactoring the Public Interface](#phase-3-refactoring-the-public-interface)
+- [Phase 4: Final Cleanup and Release Preparation](#phase-4-final-cleanup-and-release-preparation)
+
+## Phase 1: Foundation and Scaffolding
+
+***Goal**: Set up the new file structure and class names without altering existing logic. The gem will be fully functional after this phase.*
+
+1. **Create New Directory Structure**:
+
+   - Create the new directories that will house the refactored components:
+
+     - `lib/git/commands/`
+
+     - `lib/git/repository/` (for the facade modules)
+
+2. **Rename Path Classes**:
+
+   - Perform a project-wide, safe rename of the existing path-related classes. This is a low-risk mechanical change.
+
+     - `Git::WorkingDirectory` -> `Git::WorkingTreePath`
+
+     - `Git::Index` -> `Git::IndexPath`
+
+     - `Git::Repository` -> `Git::RepositoryPath`
+
+   - Run the test suite to ensure everything still works as expected.
+
+3. **Introduce New Core Classes (Empty Shells)**:
+
+   - Create the new `Git::ExecutionContext` class in `lib/git/execution_context.rb`. For now, its implementation can be a simple shell or a thin wrapper around the existing `Git::Lib`.
+
+   - Create the new `Git::Repository` class in `lib/git/repository.rb`. This will initially be an empty class.
+
+4. **Set Up RSpec Environment**:
+
+    - Add rspec dependencies to the `Gemfile` as a development dependency.
+
+    - Configure the test setup to allow both TestUnit and RSpec tests to run concurrently.
+
+## Phase 2: The Strangler Fig Pattern - Migrating Commands
+
+***Goal**: Incrementally move the implementation of each git command from `Git::Lib` to a new `Command` class, strangling the old implementation one piece at a time using a Test-Driven Development workflow.*
+
+- **1. Migrate the First Command (`config`)**:
+
+  - **Write Unit Tests First**: Write comprehensive RSpec unit tests for the *proposed* `Git::Commands::Config` class. These tests will fail initially because the class doesn't exist yet. The tests should be fast and mock the `ExecutionContext`.
+
+  - **Create Command Class**: Implement `Git::Commands::Config` to make the tests pass. This class will contain all the logic for building git config arguments and parsing its output. It will accept an `ExecutionContext` instance in its constructor.
+
+  - **Delegate from `Git::Lib`**: Modify the `config_*` methods within the existing `Git::Lib` class. Instead of containing the implementation, they will now instantiate and call the new `Git::Commands::Config` object.
+
+  - **Verify**: Run the full test suite (both TestUnit and RSpec). The existing tests for `g.config` should still pass, but they will now be executing the new, refactored code.
+
+- **2. Incrementally Migrate Remaining Commands:**
+
+  - Repeat the process from the previous step for all other commands, one by one or in logical groups (e.g., all `diff` related commands, then all `log` commands).
+
+  - For each command (`add`, `commit`, `log`, `diff`, `status`, etc.):
+
+    1. Create the corresponding Git::Commands::* class.
+
+    2. Write isolated RSpec unit tests for the new class.
+
+    3. Change the method in Git::Lib to delegate to the new command object.
+
+    4. Run the full test suite to ensure no regressions have been introduced.
+
+## Phase 3: Refactoring the Public Interface
+
+***Goal**: Switch the public-facing classes to use the new architecture directly, breaking the final ties to the old implementation.*
+
+1. **Refactor Factory Methods**:
+
+   - Modify the factory methods in the top-level `Git` module (`.open`, `.clone`, etc.).
+
+   - These methods will now be responsible for creating an instance of `Git::ExecutionContext` and injecting it into the constructor of a `Git::Repository` object.
+
+    The return value of these factories will now be a `Git::Repository` instance, not a `Git::Base` instance.
+
+2. **Implement the Facade**:
+
+   - Populate the `Git::Repository` class with the simple, one-line facade methods that delegate to the `Command` objects. For example:
+
+        ```ruby
+        def commit(msg)
+          Git::Commands::Commit.new(@execution_context, msg).run
+        end
+        ```
+
+   - Organize these facade methods into modules as planned (`lib/git/repository/branching.rb`, etc.) and include them in the main `Git::Repository` class.
+
+3. **Deprecate and Alias `Git::Base`**:
+
+   - To maintain a degree of backward compatibility through the transition, make `Git::Base` a deprecated constant that points to `Git::Repository`.
+
+        ```ruby
+        Git::Base = ActiveSupport::Deprecation::DeprecatedConstantProxy.new(
+          'Git::Base',
+          'Git::Repository',
+          Git::Deprecation
+        )
+        ```
+
+   - This ensures that any user code checking `is_a?(Git::Base)` will not immediately break.
+
+## Phase 4: Final Cleanup and Release Preparation
+
+***Goal**: Remove all old code, finalize the test suite, and prepare for the v5.0.0 release.*
+
+1. **Remove Old Code**:
+
+   - Delete the `Git::Lib` class entirely.
+
+   - Delete the `Git::Base` class file and remove the deprecation proxy.
+
+   - Remove any other dead code that was part of the old implementation.
+
+2. **Finalize Test Suite**:
+
+   - Convert any remaining, relevant TestUnit tests to RSpec.
+
+   - Remove the `test-unit` dependency from the `Gemfile`.
+
+   - Ensure the RSpec suite has comprehensive coverage for the new architecture.
+
+3. **Update Documentation**:
+
+   - Thoroughly document the new public API (`Git`, `Git::Repository`, etc.).
+
+   - Mark all internal classes (`ExecutionContext`, `Commands`, `*Path`) with `@api private` in the YARD documentation.
+
+   - Update the `README.md` and create a `UPGRADING.md` guide explaining the breaking changes for v5.0.0.

data/redesign/index.md

@@ -0,0 +1,34 @@
+# Architectural Redesign Project
+
+[This project was announced in the project's README](../README.md#2025-07-09-architectural-redesign)
+
+The git gem is undergoing a significant architectural redesign for the upcoming
+v5.0.0 release. The current architecture has several design challenges that make it
+difficult to maintain and evolve. This redesign aims to address these issues by
+introducing a clearer, more robust, and more testable structure.
+
+We have prepared detailed documents outlining the analysis of the current
+architecture and the proposed changes. We encourage our community and contributors to
+review them:
+
+1. [Analysis of the Current Architecture](1_architecture_existing.md): A
+   breakdown of the existing design and its challenges.
+2. [The Proposed Redesign](2_architecture_redesign.md): An overview of the
+   new three-layered architecture.
+3. [Implementation Plan](3_architecture_implementation.md): The step-by-step
+   plan for implementing the redesign.
+
+Your feedback is welcome! Please feel free to open an issue to discuss the proposed
+changes.
+
+> **DON'T PANIC!**
+>
+> While this is a major internal refactoring, our goal is to keep the primary public
+API on the main repository object as stable as possible. Most users who rely on
+documented methods like `g.commit`, `g.add`, and `g.status` should find the
+transition to v5.0.0 straightforward.
+>
+> The breaking changes will primarily affect users who have been relying on the
+internal g.lib accessor, which will be removed as part of this cleanup. For more
+details, please see the "Impact on Users" section in [the redesign
+> document](2_architecture_redesign.md).

data/release-please-config.json

@@ -0,0 +1,36 @@
+{
+  "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/tasks/gem_tasks.rake

@@ -0,0 +1,10 @@
+# frozen_string_literal: true
+
+require 'bundler/gem_tasks'
+
+# Make it so that calling `rake release` just calls `rake release:rubygem_push` to
+# avoid creating and pushing a new tag.
+
+Rake::Task['release'].clear
+desc 'Customized release task to avoid creating a new tag'
+task release: 'release:rubygem_push'

data/tasks/rubocop.rake

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+
+# RuboCop analyzes source text, so its verdict is fixed by TargetRubyVersion in
+# .rubocop.yml, not by the host Ruby. Skipping it on JRuby and TruffleRuby loses no
+# coverage (the MRI matrix jobs lint the same files) and avoids RuboCop internal
+# cop errors on TruffleRuby.
+#
+unless RUBY_PLATFORM == 'java' || RUBY_ENGINE == 'truffleruby'
+  require 'rubocop/rake_task'
+
+  RuboCop::RakeTask.new
+end

data/tasks/test.rake

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+desc 'Run Unit Tests'
+task :test do
+  sh 'ruby bin/test'
+
+  # You can run individual test files (or multiple files) from the command
+  # line with:
+  #
+  # $ bin/test test_archive.rb
+  #
+  # $ bin/test test_archive.rb test_object.rb
+end

data/tasks/test_gem.rake

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+
+require 'English'
+
+desc 'Build and install the git gem and run a sanity check'
+task 'test:gem': :install do
+  output = `ruby -e "require 'git'; g = Git.open('.'); puts g.log.size"`.chomp
+  raise 'Gem test failed' unless $CHILD_STATUS.success?
+  raise 'Expected gem test to return an integer' unless output =~ /^\d+$/
+
+  puts 'Gem Test Succeeded'
+end

data/tasks/yard.rake

@@ -0,0 +1,23 @@
+# frozen_string_literal: true
+
+# YARD documentation for this project can NOT be built with JRuby or TruffleRuby.
+# This project uses the redcarpet gem which can not be installed on JRuby.
+#
+unless RUBY_PLATFORM == 'java' || RUBY_ENGINE == 'truffleruby'
+  require 'yard'
+
+  YARD::Rake::YardocTask.new
+  CLEAN << '.yardoc'
+  CLEAN << 'doc'
+
+  require 'yardstick/rake/verify'
+  Yardstick::Rake::Verify.new(:'yardstick:coverage') do |t|
+    t.threshold = 50
+    t.require_exact_threshold = false
+  end
+
+  desc 'Run yardstick to check yard docs'
+  task :yardstick do
+    sh "yardstick 'lib/**/*.rb'"
+  end
+end