git 4.1.0 → 4.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 46a0a933115990124037806bd799be30b6ade9a6e00929062ab87ca8c320539f
-  data.tar.gz: f91ebc5061789e42d12e9ba5a50c26958b8ffe5f5f9751685c3e28b85551f763
+  metadata.gz: 547a803a734580e23f5e1f6910f54c2437bcb165331d1d2d9048a2fb2ff1180f
+  data.tar.gz: 9532b6e51177204f789aab40b2d551d8886abf524f50f9366a60045f00e2cc7f
 SHA512:
-  metadata.gz: 4d83c53f966a90497b698d312b102069d49a39e7f87586b181de0ddc5e45ae4ee833719318674c0d5f6fa5c26780b5c7ec60b95230afa7a4541648db0f7739f5
-  data.tar.gz: a60047e9d3e22307268b63efb55ee0dcc2e295348438059c7da486ba5050feb9bbbc0300d3bc2fba3c363ede1e5aaa396e1662c8aef1c819d606a0319e4f5fe0
+  metadata.gz: 31f1da3bc8b566f4990efd1651ed59202eabd424722693e0fae1b41ec194d4bbd2f7c613ed7552035b6ca42b6d501459b0d9d323bd188957ed5291675ff506de
+  data.tar.gz: eb4a424bdfbc1fcda445e880b8497ff714fe2c575591a5c48ee8c37f36e721f38474dd409c0af85fddbd98570a8ac7e5e5ba8c4e6c994fce46108e9f349f8137

data/.github/copilot-instructions.md

@@ -2540,21 +2540,49 @@ automated releases based on conventional commits.
 
 **Branch Strategy:**
 
+This project maintains two active branches:
+
+- **`main`**: Active development for the next major version (v5.0.0+). May contain
+  breaking changes.
+- **`4.x`**: Maintenance branch for the v4.x release series. Bug fixes and
+  backward-compatible improvements only.
+
+**Important:** Never commit directly to `main` or `4.x`. All changes must be
+submitted via pull requests from feature branches. This ensures proper code review,
+CI validation, and maintains a clean commit history.
+
+**For new features and breaking changes (target `main`):**
+
 1. Ensure local main is up-to-date: `git fetch origin main`
 2. Create a new branch from origin/main: `git checkout -b feature/your-feature
    origin/main`
 3. Make your changes following TDD
 4. Ensure all tests pass and code quality checks pass
-5. Push the branch and create a PR
+5. Push the branch and create a PR targeting `main`
+
+**For bug fixes (target `main`, maintainers backport to `4.x` if applicable):**
+
+1. Ensure local main is up-to-date: `git fetch origin main`
+2. Create a new branch from origin/main: `git checkout -b fix/your-fix origin/main`
+3. Make your changes following TDD
+4. Push the branch and create a PR targeting `main`
+
+**For security fixes or 4.x-only changes (target `4.x`):**
+
+1. Ensure local 4.x is up-to-date: `git fetch origin 4.x`
+2. Create a new branch from origin/4.x: `git checkout -b fix/your-fix origin/4.x`
+3. Make your changes following TDD
+4. Push the branch and create a PR targeting `4.x`
 
 **When Submitting Existing Changes:**
 
-- Ensure changes are on a feature branch (not `main`), following the naming
+- Ensure changes are on a feature branch (not `main` or `4.x`), following the naming
   convention `<type>/<short-description>`
-- If changes are on the wrong branch, offer to create a new branch from
-  `origin/main` and relocate the user's existing work (commits or uncommitted
-  changes) onto that new branch, choosing an appropriate Git approach (for
-  example, cherry-pick, rebase, or recommitting) based on the situation
+- If changes are on the wrong branch, offer to create a new branch from the
+  appropriate base branch (`origin/main` or `origin/4.x`) and relocate the user's
+  existing work (commits or uncommitted changes) onto that new branch, choosing an
+  appropriate Git approach (for example, cherry-pick, rebase, or recommitting) based
+  on the situation
 
 **PR Creation Automation:**
 

data/.github/pull_request_template.md

@@ -1,8 +1,17 @@
 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
+- 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.
+- [ ] Tests added/updated as needed and `rake` passes locally.
+- [ ] Documentation updated where applicable (README and/or YARD).

data/.github/workflows/continuous_integration.yml

@@ -2,7 +2,7 @@ name: CI
 
 on:
   pull_request:
-    branches: [main]
+    branches: [main, 4.x]
   workflow_dispatch:
 
 jobs:

data/.github/workflows/enforce_conventional_commits.yml

@@ -8,6 +8,7 @@ on:
   pull_request:
     branches:
       - main
+      - 4.x
 
 jobs:
   commit-lint:

data/.github/workflows/release.yml

@@ -11,7 +11,7 @@ description: |
 
 on:
   push:
-    branches: ["main"]
+    branches: ["main", "4.x"]
 
   workflow_dispatch:
 

data/.release-please-manifest.json

@@ -1,3 +1,3 @@
 {
-  ".": "4.1.0"
+  ".": "4.1.2"
 }

data/.yardopts

@@ -6,5 +6,9 @@
 -
 README.md
 CHANGELOG.md
+CODE_OF_CONDUCT.md
 CONTRIBUTING.md
+AI_POLICY.md
+GOVERNANCE.md
 MAINTAINERS.md
+LICENSE

data/AI_POLICY.md

@@ -0,0 +1,24 @@
+<!--
+# @markup markdown
+# @title AI Policy
+-->
+
+# AI Policy
+
+AI assisted contributions are welcome in this project.
+
+Reviewing and maintaining code requires human insight. While AI tools can be helpful
+assistants, they are no substitute for human judgment and creativity.
+
+We value the unique perspectives and critical thinking that our contributors bring.
+If you use AI tools to assist your work:
+
+1. **You are responsible**: You must review and understand every line of code or text
+   you submit.
+2. **Focus on quality**: Ensure that AI-generated content meets our standards for
+   correctness, readability, and security, and respects all licensing requirements.
+3. **Be transparent**: We encourage you to disclose if significant portions of your
+   contribution were AI-generated.
+
+Ultimately, the quality of this project depends on *your* expertise. Use tools
+wisely, but lead with your own intelligence.

data/CHANGELOG.md

@@ -5,6 +5,27 @@
 
 # Change Log
 
+## [4.1.2](https://github.com/ruby-git/ruby-git/compare/v4.1.1...v4.1.2) (2026-01-10)
+
+
+### Other Changes
+
+* Add Continuity section to Governance ([a2f644c](https://github.com/ruby-git/ruby-git/commit/a2f644c0caa7b60137e0a1ef79eabaf880d18ac6))
+* Add Roberto Decurnex to Maintainers Emeritus ([5104537](https://github.com/ruby-git/ruby-git/commit/5104537e15c5d14357c353b08706973c2669ad31))
+* Enable releases from 4.x maintenance branch ([5377de6](https://github.com/ruby-git/ruby-git/commit/5377de602e6ecd947d3feadb3df49d6a63556f53))
+* Move inactive maintainers to Emeritus per governance policy ([f09e4d1](https://github.com/ruby-git/ruby-git/commit/f09e4d1e68cd5db6535ba737720eb495ea8422ec))
+
+## [4.1.1](https://github.com/ruby-git/ruby-git/compare/v4.1.0...v4.1.1) (2026-01-09)
+
+
+### Other Changes
+
+* Add AI Policy and update documentation ([8616cdf](https://github.com/ruby-git/ruby-git/commit/8616cdf7c6cfd1a3f2ccb931f59367b0fdfa36d1))
+* Add code of conduct links ([0769c8e](https://github.com/ruby-git/ruby-git/commit/0769c8ede791a2578291fa301d74144bc7fb2bfb))
+* Add governance policy and update project policies ([8d8263c](https://github.com/ruby-git/ruby-git/commit/8d8263c8395ff4e127b7dc6eb25b0371c272593a))
+* Add Quick Start section and reorganize README for new users ([1811a75](https://github.com/ruby-git/ruby-git/commit/1811a75e4b0b8b8233988d38a411ba585f35c044))
+* Clarify JRuby on Windows support policy ([c37b3d6](https://github.com/ruby-git/ruby-git/commit/c37b3d6c256cdc925578c7ff198f6b351dcb5844))
+
 ## [4.1.0](https://github.com/ruby-git/ruby-git/compare/v4.0.7...v4.1.0) (2026-01-02)
 
 

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,25 @@
+<!--
+# @markup markdown
+# @title Code of Conduct
+-->
+
+# Code of Conduct
+
+ℹ️ We have adopted the [Ruby code of conduct](https://www.ruby-lang.org/en/conduct/).
+
+This document provides community guidelines for a safe, respectful, productive, and
+collaborative place for any person who is willing to contribute to the Ruby
+community. It applies to all “collaborative space”, which is defined as community
+communications channels (such as mailing lists, submitted patches, commit comments,
+etc.).
+
+- Participants will be tolerant of opposing views.
+- Participants must ensure that their language and actions are free of personal
+  attacks and disparaging personal remarks.
+- When interpreting the words and actions of others, participants should always
+  assume good intentions.
+- Behavior which can be reasonably considered harassment will not be tolerated.
+
+Report violations to the maintainers by [opening an
+issue](https://github.com/ruby-git/ruby-git/issues/new) or contacting a
+[maintainer](MAINTAINERS.md) privately.

data/CONTRIBUTING.md

@@ -12,6 +12,8 @@
   - [Commit your changes to a fork of `ruby-git`](#commit-your-changes-to-a-fork-of-ruby-git)
   - [Create a pull request](#create-a-pull-request)
   - [Get your pull request reviewed](#get-your-pull-request-reviewed)
+- [Branch strategy](#branch-strategy)
+- [AI-assisted contributions](#ai-assisted-contributions)
 - [Design philosophy](#design-philosophy)
   - [Direct mapping to git commands](#direct-mapping-to-git-commands)
   - [Parameter naming](#parameter-naming)
@@ -41,6 +43,11 @@ judgment when contributing.
 If you have suggestions for improving these guidelines, please propose changes via a
 pull request.
 
+Please also review and adhere to our [Code of Conduct](CODE_OF_CONDUCT.md) when
+participating in the project.
+Governance and maintainer expectations are described in
+[GOVERNANCE.md](GOVERNANCE.md).
+
 ## How to contribute
 
 You can contribute in the following ways:
@@ -91,13 +98,39 @@ Once your pull request is ready for review, request a review from at least one
 [maintainer](MAINTAINERS.md) and any other contributors you deem necessary.
 
 During the review process, you may need to make additional commits, which should be
-squashed. Additionally, you may need to rebase your branch to the latest `master`
-branch if other changes have been merged.
+squashed. Additionally, you will need to rebase your branch to the latest version of
+the target branch (e.g., `main` or `4.x`) before merging.
 
 At least one approval from a project maintainer is required before your pull request
 can be merged. The maintainer is responsible for ensuring that the pull request meets
 [the project's coding standards](#coding-standards).
 
+## Branch strategy
+
+This project maintains two active branches:
+
+- **`main`**: Active development for the next major version (v5.0.0+). This branch
+  may contain breaking changes.
+- **`4.x`**: Maintenance branch for the v4.x release series. This branch receives
+  bug fixes and backward-compatible improvements only.
+
+**Important:** Never commit directly to `main` or `4.x`. All changes must be
+submitted via pull requests from feature branches. This ensures proper code review,
+CI validation, and maintains a clean commit history.
+
+When submitting a pull request:
+
+- **New features and breaking changes**: Target the `main` branch
+- **Bug fixes**: Target `main`, and maintainers will backport to `4.x` if applicable
+- **Security fixes**: Target both branches or `4.x` if the issue only affects v4.x
+
+## AI-assisted contributions
+
+AI-assisted contributions are welcome. Please review and apply our [AI Policy](AI_POLICY.md)
+before submitting changes. You are responsible for understanding and verifying any
+AI-assisted work included in PRs and ensuring it meets our standards for quality,
+security, and licensing.
+
 ## Design philosophy
 
 *Note: As of v2.x of the `git` gem, this design philosophy is aspirational. Future

data/GOVERNANCE.md

@@ -0,0 +1,106 @@
+<!--
+# @markup markdown
+# @title Governance
+-->
+
+# Governance
+
+This document explains how we steward the project with a light, principles-first
+approach: enable trusted people, minimize dormant access, and keep decisions
+transparent.
+
+## Roles
+
+A **Maintainer** is a trusted leader with write access who stewards the project's
+health and direction. Responsibilities center on triage, review, merge, and
+helping the community stay unblocked.
+
+A **Project Lead** is a maintainer with additional administrative scope (repo
+Admin, org Owner). They handle settings, secrets, access, and tie-breaks when
+needed.
+
+## Becoming a Maintainer
+
+Maintainers invite contributors who consistently ship, review, and model our
+values to become maintainers. Anyone can nominate themselves or others in an
+issue or via a private note. Current maintainers discuss nominations (see
+[Decision Making](#decision-making)) with a focus on contribution quality,
+alignment with project goals, and communication style.
+
+## Access Principles
+
+- Stewardship: Maintainer access exists to keep the project healthy and responsive.
+- Least privilege: Elevated access is temporary and kept only while it’s needed.
+- Continuity: Dormant access is paused to protect the project and unblock
+  contributors.
+- Respect: Status changes are transparent, reversible, and acknowledge past
+  contributions.
+
+## How We Apply Them
+
+- Staying active: Maintainers keep elevated access while participating (shipping,
+  reviewing, triaging, or governance).
+- When access is paused: If there’s no project activity for about a year, we’ll
+  check in. If we don’t hear back after a short window, we move the maintainer to
+  Emeritus and pause Owner/Admin/Write/package access (including CODEOWNERS
+  entries).
+- Coming back: Emeritus maintainers can be re-added quickly after a brief period of
+  renewed participation to refresh context.
+- Recognition: Emeritus maintainers remain listed to honor prior contributions.
+
+Access changes are communicated openly (e.g., PRs or issues) and reflected in the
+Maintainers list.
+
+## Decision Making
+
+Decisions are usually made by consensus among the active maintainers. If consensus
+cannot be reached, the decision is made by a majority vote. If a vote results in a
+tie, the Project Lead has the final say.
+
+## Continuity
+
+The project must be able to ship releases and respond to security issues even if
+individual maintainers become unavailable.
+
+### RubyGems Ownership
+
+RubyGems ownership (the ability to push new gem versions) is granted to a subset
+of active maintainers—typically the Project Lead and at least one other
+maintainer—to balance security with continuity. Not all maintainers require
+RubyGems access.
+
+RubyGems owners follow the same activity principles as other elevated access: if
+an owner becomes inactive, their ownership is paused alongside other permissions.
+
+### Minimum Thresholds
+
+To avoid single points of failure:
+
+- At least two active maintainers should have RubyGems ownership for the `git` gem.
+- At least two active maintainers should have GitHub org Owner or repo Admin
+  access.
+
+If thresholds drop below these levels, remaining maintainers should prioritize
+onboarding or re-activating someone to restore redundancy.
+
+### Access Audits
+
+Periodically (at least annually), maintainers review access across all systems:
+
+- GitHub organization membership and roles
+- GitHub repository admin/write permissions
+- RubyGems gem ownership
+- GitHub Actions release automation: PATs/OIDC tokens (e.g., `AUTO_RELEASE_TOKEN` scope),
+  environment protection rules/approvers for RubyGems deployments, and any OIDC
+  trust configuration
+
+The Project Lead (or a delegated maintainer) schedules and drives this review so
+continuity checks do not slip.
+
+Audits ensure access reflects current activity and that continuity thresholds are
+met.
+
+## Code of Conduct
+
+All maintainers and contributors must adhere to the project's [Code of
+Conduct](./CODE_OF_CONDUCT.md).

data/MAINTAINERS.md

@@ -5,8 +5,21 @@
 
 # Maintainers
 
-When making changes in this repository, one of the maintainers below must review and approve your pull request.
+See [GOVERNANCE.md](GOVERNANCE.md) for a definition of the Maintainer role.
 
-* [James Couball](https://github.com/jcouball)
-* [Frank Throckmorton](https://github.com/frankthrock)
-* [Per Lundberg](https://github.com/perlun)
+## Active Maintainers
+
+- [James Couball](https://github.com/jcouball) (Project Lead)
+- [Frank Throckmorton](https://github.com/frankthrock)
+
+## Maintainers Emeritus (Alumni)
+
+**Maintainers Emeritus** are former maintainers who are no longer active. We honor
+their past contributions.
+
+- [Per Lundberg](https://github.com/perlun)
+- [Vern Burton](https://github.com/tarcinil)
+- [Daniel Perez](https://github.com/dpmex4527)
+- [Richard Vodden](https://github.com/rvodden)
+- [Roberto Decurnex](https://github.com/robertodecurnex)
+- [Scott Chacon](https://github.com/schacon) (original creator)