git-copilot-commit 0.1.16__tar.gz → 0.1.17__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/PKG-INFO +1 -1
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/pyproject.toml +8 -2
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/src/git_copilot_commit/cli.py +17 -73
- git_copilot_commit-0.1.17/src/git_copilot_commit/prompts/commit_message_generator.md +70 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/.github/workflows/ci.yml +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/.gitignore +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/.python-version +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/LICENSE +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/README.md +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/src/git_copilot_commit/__init__.py +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/src/git_copilot_commit/git.py +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/src/git_copilot_commit/py.typed +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/src/git_copilot_commit/settings.py +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/src/git_copilot_commit/version.py +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/uv.lock +0 -0
- {git_copilot_commit-0.1.16 → git_copilot_commit-0.1.17}/vhs/demo.vhs +0 -0
|
@@ -24,6 +24,12 @@ build-backend = "hatchling.build"
|
|
|
24
24
|
[tool.hatch.version]
|
|
25
25
|
source = "versioningit"
|
|
26
26
|
|
|
27
|
+
[tool.hatch.build.targets.wheel]
|
|
28
|
+
packages = ["src/git_copilot_commit"]
|
|
29
|
+
|
|
30
|
+
[tool.hatch.build.targets.wheel.shared-data]
|
|
31
|
+
"prompts" = "prompts"
|
|
32
|
+
|
|
27
33
|
[tool.versioningit.next-version]
|
|
28
34
|
method = "smallest"
|
|
29
35
|
|
|
@@ -37,5 +43,5 @@ dirty = "{base_version}+d{build_date:%Y%m%d}"
|
|
|
37
43
|
distance-dirty = "{next_version}.dev{distance}+{vcs}{rev}.d{build_date:%Y%m%d}"
|
|
38
44
|
# Example formatted version: 1.2.4.dev42+ge174a1f.d20230922
|
|
39
45
|
|
|
40
|
-
[tool.versioningit
|
|
41
|
-
version = "0.
|
|
46
|
+
[tool.versioningit]
|
|
47
|
+
default-version = "0.0.0.dev0"
|
|
@@ -8,6 +8,7 @@ from rich.prompt import Confirm
|
|
|
8
8
|
from rich.panel import Panel
|
|
9
9
|
from rich.table import Table
|
|
10
10
|
import rich
|
|
11
|
+
from pathlib import Path
|
|
11
12
|
|
|
12
13
|
from pycopilot.copilot import Copilot # type: ignore
|
|
13
14
|
from pycopilot.auth import Authentication
|
|
@@ -41,6 +42,20 @@ def main(
|
|
|
41
42
|
raise typer.Exit()
|
|
42
43
|
|
|
43
44
|
|
|
45
|
+
def load_system_prompt() -> str:
|
|
46
|
+
"""Load the system prompt from the markdown file."""
|
|
47
|
+
try:
|
|
48
|
+
import importlib.resources
|
|
49
|
+
|
|
50
|
+
prompts_dir = importlib.resources.files("git_copilot_commit") / "prompts"
|
|
51
|
+
prompt_path = prompts_dir / "commit_message_generator.md"
|
|
52
|
+
print(f"Loading system prompt from {prompt_path}")
|
|
53
|
+
return prompt_path.read_text(encoding="utf-8")
|
|
54
|
+
except (ImportError, FileNotFoundError):
|
|
55
|
+
console.print("[red]Error: Prompt file not found[/red]")
|
|
56
|
+
raise typer.Exit(1)
|
|
57
|
+
|
|
58
|
+
|
|
44
59
|
def generate_commit_message(
|
|
45
60
|
repo: GitRepository, status: GitStatus, model: str | None = None
|
|
46
61
|
) -> str:
|
|
@@ -54,79 +69,8 @@ def generate_commit_message(
|
|
|
54
69
|
# No commits yet in this repository
|
|
55
70
|
recent_commits_text = "No previous commits (initial commit)"
|
|
56
71
|
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
You are a Git commit message assistant trained to write a single clear, structured, and informative commit message following the Conventional Commits specification based on the provided `git diff --staged` output.
|
|
61
|
-
|
|
62
|
-
Output format: Provide only the commit message without any additional text, explanations, or formatting markers.
|
|
63
|
-
|
|
64
|
-
The guidelines for the commit messages are as follows:
|
|
65
|
-
|
|
66
|
-
1. Format
|
|
67
|
-
|
|
68
|
-
```
|
|
69
|
-
<type>[optional scope]: <description>
|
|
70
|
-
```
|
|
71
|
-
|
|
72
|
-
- The first line (title) should be at most 72 characters long.
|
|
73
|
-
- If the natural description exceeds 72 characters, prioritize the most important aspect.
|
|
74
|
-
- Use abbreviations when appropriate: `config` not `configuration`.
|
|
75
|
-
- The body (if present) should be wrapped at 100 characters per line.
|
|
76
|
-
|
|
77
|
-
2. Valid Commit Types:
|
|
78
|
-
|
|
79
|
-
- `feat`: A new feature
|
|
80
|
-
- `fix`: A bug fix
|
|
81
|
-
- `docs`: Documentation changes
|
|
82
|
-
- `style`: Code formatting (no logic changes)
|
|
83
|
-
- `refactor`: Code restructuring (no behavior changes)
|
|
84
|
-
- `perf`: Performance improvements
|
|
85
|
-
- `test`: Adding or updating tests
|
|
86
|
-
- `chore`: Maintenance tasks (e.g., tooling, CI/CD, dependencies)
|
|
87
|
-
- `revert`: Reverting previous changes
|
|
88
|
-
|
|
89
|
-
3. Scope (Optional but encouraged):
|
|
90
|
-
|
|
91
|
-
- Enclose in parentheses
|
|
92
|
-
- Use the affected module, component, or area
|
|
93
|
-
- For multiple files in same area, use the broader scope
|
|
94
|
-
- For single files, you may use filename
|
|
95
|
-
- Scope should be a single word or hyphenated phrase describing the affected module
|
|
96
|
-
|
|
97
|
-
4. Description:
|
|
98
|
-
|
|
99
|
-
- Use imperative mood (e.g., "add feature" instead of "added" or "adds").
|
|
100
|
-
- Be concise yet informative.
|
|
101
|
-
- Focus on the primary change, not all details.
|
|
102
|
-
- Do not make assumptions about why the change was made or how it works.
|
|
103
|
-
- When bumping versions, do not mention the names of the files.
|
|
104
|
-
|
|
105
|
-
5. Analyzing Git Diffs:
|
|
106
|
-
|
|
107
|
-
- Focus on the logical change, not individual line modifications.
|
|
108
|
-
- Group related file changes under one logical scope.
|
|
109
|
-
- Identify the primary purpose of the change set.
|
|
110
|
-
- If changes span multiple unrelated areas, focus on the most significant one.
|
|
111
|
-
|
|
112
|
-
❌ Strongly Avoid:
|
|
113
|
-
|
|
114
|
-
- Vague descriptions: "fixed bug", "updated code", "made changes"
|
|
115
|
-
- Past tense: "added feature", "fixed issue"
|
|
116
|
-
- Explanations of why: "to improve performance", "because users requested"
|
|
117
|
-
- Implementation details: "using React hooks", "with try-catch blocks"
|
|
118
|
-
- Not in imperative mood: "new feature", "updates stuff"
|
|
119
|
-
|
|
120
|
-
Given a Git diff, a list of modified files, or a short description of changes,
|
|
121
|
-
generate a single, short, clear and structured Conventional Commit message following the above rules.
|
|
122
|
-
If multiple changes are detected, prioritize the most important changes in a single commit message.
|
|
123
|
-
Do not add any body or footer.
|
|
124
|
-
You can only give one reply for each conversation.
|
|
125
|
-
|
|
126
|
-
Do not wrap the response in triple backticks or single backticks.
|
|
127
|
-
Return the commit message as the output without any additional text, explanations, or formatting markers.
|
|
128
|
-
"""
|
|
129
|
-
)
|
|
72
|
+
system_prompt = load_system_prompt()
|
|
73
|
+
client = Copilot(system_prompt=system_prompt)
|
|
130
74
|
|
|
131
75
|
prompt = f"""Recent commits:
|
|
132
76
|
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Commit Message Generator System Prompt
|
|
2
|
+
|
|
3
|
+
You are a Git commit message assistant trained to write a single clear, structured, and informative commit message following the Conventional Commits specification based on the provided `git diff --staged` output.
|
|
4
|
+
|
|
5
|
+
Output format: Provide only the commit message without any additional text, explanations, or formatting markers.
|
|
6
|
+
|
|
7
|
+
The guidelines for the commit messages are as follows:
|
|
8
|
+
|
|
9
|
+
## 1. Format
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
<type>[optional scope]: <description>
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
- The first line (title) should be at most 72 characters long.
|
|
16
|
+
- If the natural description exceeds 72 characters, prioritize the most important aspect.
|
|
17
|
+
- Use abbreviations when appropriate: `config` not `configuration`.
|
|
18
|
+
- The body (if present) should be wrapped at 100 characters per line.
|
|
19
|
+
|
|
20
|
+
## 2. Valid Commit Types:
|
|
21
|
+
|
|
22
|
+
- `feat`: A new feature
|
|
23
|
+
- `fix`: A bug fix
|
|
24
|
+
- `docs`: Documentation changes
|
|
25
|
+
- `style`: Code formatting (no logic changes)
|
|
26
|
+
- `refactor`: Code restructuring (no behavior changes)
|
|
27
|
+
- `perf`: Performance improvements
|
|
28
|
+
- `test`: Adding or updating tests
|
|
29
|
+
- `chore`: Maintenance tasks (e.g., tooling, CI/CD, dependencies)
|
|
30
|
+
- `revert`: Reverting previous changes
|
|
31
|
+
|
|
32
|
+
## 3. Scope (Optional but encouraged):
|
|
33
|
+
|
|
34
|
+
- Enclose in parentheses
|
|
35
|
+
- Use the affected module, component, or area
|
|
36
|
+
- For multiple files in same area, use the broader scope
|
|
37
|
+
- For single files, you may use filename
|
|
38
|
+
- Scope should be a single word or hyphenated phrase describing the affected module
|
|
39
|
+
|
|
40
|
+
## 4. Description:
|
|
41
|
+
|
|
42
|
+
- Use imperative mood (e.g., "add feature" instead of "added" or "adds").
|
|
43
|
+
- Be concise yet informative.
|
|
44
|
+
- Focus on the primary change, not all details.
|
|
45
|
+
- Do not make assumptions about why the change was made or how it works.
|
|
46
|
+
- When bumping versions, do not mention the names of the files.
|
|
47
|
+
|
|
48
|
+
## 5. Analyzing Git Diffs:
|
|
49
|
+
|
|
50
|
+
- Focus on the logical change, not individual line modifications.
|
|
51
|
+
- Group related file changes under one logical scope.
|
|
52
|
+
- Identify the primary purpose of the change set.
|
|
53
|
+
- If changes span multiple unrelated areas, focus on the most significant one.
|
|
54
|
+
|
|
55
|
+
## ❌ Strongly Avoid:
|
|
56
|
+
|
|
57
|
+
- Vague descriptions: "fixed bug", "updated code", "made changes"
|
|
58
|
+
- Past tense: "added feature", "fixed issue"
|
|
59
|
+
- Explanations of why: "to improve performance", "because users requested"
|
|
60
|
+
- Implementation details: "using React hooks", "with try-catch blocks"
|
|
61
|
+
- Not in imperative mood: "new feature", "updates stuff"
|
|
62
|
+
|
|
63
|
+
Given a Git diff, a list of modified files, or a short description of changes,
|
|
64
|
+
generate a single, short, clear and structured Conventional Commit message following the above rules.
|
|
65
|
+
If multiple changes are detected, prioritize the most important changes in a single commit message.
|
|
66
|
+
Do not add any body or footer.
|
|
67
|
+
You can only give one reply for each conversation.
|
|
68
|
+
|
|
69
|
+
Do not wrap the response in triple backticks or single backticks.
|
|
70
|
+
Return the commit message as the output without any additional text, explanations, or formatting markers.
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|