49 lines
3.4 KiB
Markdown
49 lines
3.4 KiB
Markdown
# Git Guide
|
|
|
|
This file records repo-specific git workflow preferences for `/home/aw/code/cds`.
|
|
|
|
## Repository Reference
|
|
- Active repository: `https://git.devreser.com/anthony.wen/cds-ai.git`
|
|
- Treat this repository URL as the current `origin` for this workspace unless the user explicitly says it changed.
|
|
|
|
## Commit Message Requests
|
|
- If the user asks for a git commit description, draft the proposed commit message first.
|
|
- When warranted by the size or complexity of the change, provide both:
|
|
- a concise commit title/summary line
|
|
- a detailed commit description/body listing the key changes
|
|
- The proposed `git commit` command should match the full proposed message, including the detailed body when one is warranted.
|
|
- After the proposed commit message, show the exact `git commit` command that would be used.
|
|
- After the `git commit` command, show the exact `git push -u origin main` command that would be used.
|
|
- If the user asks for a git commit, do not commit immediately.
|
|
- First show both:
|
|
- the proposed commit description/message
|
|
- the exact `git commit` command planned for execution
|
|
- When a detailed body is warranted, do not reduce the proposed commit to only the short title at execution time.
|
|
- Do not run `git commit` immediately after drafting the message.
|
|
- Do not run `git push` immediately after drafting the message.
|
|
- Wait for explicit user approval before creating the commit or running the push command.
|
|
- Do not treat a request such as "give me the git commit" or "make the commit" as approval by itself.
|
|
- Do not treat a request such as "create a git for me", "show me a proposed git commit", "prepare the commit", or any similar commit-related wording as approval by itself.
|
|
- Treat every commit-related request as prepare-and-show-only until the user explicitly approves the commit after seeing the proposed message or exact command.
|
|
- Only execute `git commit` after the user explicitly approves the displayed commit command.
|
|
- If there is any ambiguity about whether the user is asking for preparation versus execution, default to not committing.
|
|
- If the user changes the requested commit message or scope after commands are shown, rebuild the proposal and wait for fresh approval.
|
|
- After executing `git commit`, always verify that the commit actually succeeded before reporting success.
|
|
- Verification must include checking that:
|
|
- `git commit` exited successfully
|
|
- `HEAD` advanced to a new commit
|
|
- the new commit appears in `git log --oneline -n 1`
|
|
- Do not claim a commit was created unless that verification has been completed.
|
|
- If `git commit` did not actually create a commit, report that clearly and leave the changes as uncommitted.
|
|
|
|
## Push Requests
|
|
- When the user asks to push, use `git push -u origin main` by default unless the user explicitly asks for a different remote or branch.
|
|
- Do not execute `git push -u origin main` or any other git push command from the assistant when credentials or an SSH key passphrase might be required.
|
|
- Instead, show the exact push command and tell the user to run it directly in the terminal.
|
|
- Do not accept passwords or passphrases through chat for git operations.
|
|
- If the user asks the assistant to take the password/passphrase handoff, refuse and direct the user to complete the prompt from the terminal.
|
|
|
|
## Commit Scope
|
|
- When committing, include only the files relevant to the approved change.
|
|
- Leave unrelated worktree changes uncommitted unless the user explicitly asks to include them.
|