rm-hull / rm-hull/git-commit-summary

Repository-Specific Configuration (.git-commit-summary.yaml / project config)

Open
#184 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
0
Forks
0
Avg merge
18h 49m
Merged PRs (30d)
13

Description

Problem Statement

Currently, git-commit-summary loads configuration exclusively from global/XDG locations (~/.config/git-commit-summary/config.env) and local .env files in the working directory root. It does not support repository-specific configuration files (e.g., .git-commit-summary.yaml or project-level .env/config files) that can be checked into version control.

Proposed Feature: Repository-Specific Configuration

Allow individual Git repositories to define their own commit standards, prompts, LLM model preferences, and exclusion rules directly inside the repository.


Detailed Outline Plan
  1. Config Discovery & Precedence:

    • Extend internal/config to search for a repository-specific configuration file (e.g., .git-commit-summary.yaml or .git-commit-summary.env) in the current working directory or repository root (walking up to the git worktree root).
    • Establish clear configuration precedence:
      1. CLI flags / environment variables (highest priority)
      2. Repository-specific config (.git-commit-summary.yaml / .env in repo root)
      3. User local .env file
      4. XDG global configuration (~/.config/git-commit-summary/config.env) (lowest priority)
  2. Schema & Fields:

    • Support project-level settings such as:
      • Preferred LLM provider and model (LLM_PROVIDER, GEMINI_MODEL, etc.)
      • Custom system prompt or prompt template path
      • Additional project-specific file exclusions or overrides
  3. Testing & Validation:

    • Add unit tests in internal/config verifying correct configuration merging and precedence order when repository configs are present.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the existing configuration loading code and tests under internal/config to understand global/XDG and local .env behavior. Trace how the current working directory and Git worktree are identified, then define the repository-config format and precedence from the issue. Done means repository-specific settings merge correctly and internal/config tests cover discovery, merging, and precedence.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.