| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 0 | 9 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 0 | 3 | 0% |
What each file covers
Sections
0 shared · 0 only in A · 9 only in B- + Git Commit Message Guidelines
- + Overview
- + Message Structure
- + Types
- + Subject Guidelines
- + Body Guidelines
- + Footer Guidelines
- + Examples
- + Additional Guidelines
Commands
neither file has anySection tags
0 shared · 0 only in A · 3 only in B- + architecture
- + types
- + git-pr
Line diff
tyler274/rummage · .cursor/rules/mtg.mdc
@@ −1 @@
1---
2description: Magic the Gathering Rules
3globs:
4alwaysApply: false
5---
6[MagicCompRules 20250207.txt](mdc:docs/mtg_rules/MagicCompRules 20250207.txt) Refer to this as the source of truth for all Magic the
7Gathering rules and edge cases that need to be handled robustly in the game engine.
tyler274/rummage · .cursor/rules/git_commits.mdc
@@ +1 @@
1---
2description: Git commit message guidelines
3globs:
4alwaysApply: false
5---
6# Git Commit Message Guidelines
7
8## Overview
9This rule outlines best practices for creating clear, informative git commit messages that make the repository history easy to understand and navigate. All commit messages should follow this standard format.
10
11## Message Structure
12Each commit message should follow this structure:
13
14```
15<type>: <subject>
16
17<body>
18
19<footer>
20```
21
22## Types
23Begin your commit message with one of these types:
24
25- `feat`: A new feature
26- `fix`: A bug fix
27- `docs`: Documentation changes
28- `style`: Code style changes (formatting, indentation)
29- `refactor`: Code refactoring (no functional changes)
30- `perf`: Performance improvements
31- `test`: Adding or updating tests
32- `chore`: Maintenance tasks, build changes, etc.
33- `ci`: CI/CD related changes
34
35## Subject Guidelines
36- Write in imperative mood (e.g., "Add" not "Added" or "Adds")
37- Keep it under 50 characters
38- Don't end with a period
39- Capitalize the first letter
40
41## Body Guidelines
42- Separate from subject with a blank line
43- Explain the "what" and "why" (not "how")
44- Use bullet points when appropriate (- or *)
45- Wrap text at ~72 characters
46- Reference issues and user stories when applicable
47
48## Footer Guidelines
49- Reference issues with "Fixes #123" or "Closes #123"
50- Breaking changes should be noted with "BREAKING CHANGE:"
51
52## Examples
53
54```
55feat: Add user authentication system
56
57Implement JWT-based authentication flow with refresh tokens.
58- Add login/logout endpoints
59- Create token generation service
60- Add middleware for protected routes
61
62Closes #45
63```
64
65```
66fix: Prevent race condition in database connection pool
67
68When multiple requests arrived simultaneously during
69initialization, connections were being created beyond
70the configured maximum. Added mutex lock to ensure
71proper counting.
72
73Fixes #123
74```
75
76```
77docs: Update API documentation with authentication examples
78
79Add code samples for all authentication flows and
80improve explanations of token usage.
81```
82
83## Additional Guidelines
84- When possible, limit commits to a single logical change
85- Small, focused commits are easier to understand and review
86- Avoid mixing multiple unrelated changes in a single commit
87- When incorporating feedback from PR reviews, reference the PR number
@@ −1 +1 @@
11 ---
2−description: Magic the Gathering Rules
2+description: Git commit message guidelines
33 globs:
44 alwaysApply: false
55 ---
6−[MagicCompRules 20250207.txt](mdc:docs/mtg_rules/MagicCompRules 20250207.txt) Refer to this as the source of truth for all Magic the
7−Gathering rules and edge cases that need to be handled robustly in the game engine.
6+# Git Commit Message Guidelines
7+
8+## Overview
9+This rule outlines best practices for creating clear, informative git commit messages that make the repository history easy to understand and navigate. All commit messages should follow this standard format.
10+
11+## Message Structure
12+Each commit message should follow this structure:
13+
14+```
15+<type>: <subject>
16+
17+<body>
18+
19+<footer>
20+```
21+
22+## Types
23+Begin your commit message with one of these types:
24+
25+- `feat`: A new feature
26+- `fix`: A bug fix
27+- `docs`: Documentation changes
28+- `style`: Code style changes (formatting, indentation)
29+- `refactor`: Code refactoring (no functional changes)
30+- `perf`: Performance improvements
31+- `test`: Adding or updating tests
32+- `chore`: Maintenance tasks, build changes, etc.
33+- `ci`: CI/CD related changes
34+
35+## Subject Guidelines
36+- Write in imperative mood (e.g., "Add" not "Added" or "Adds")
37+- Keep it under 50 characters
38+- Don't end with a period
39+- Capitalize the first letter
40+
41+## Body Guidelines
42+- Separate from subject with a blank line
43+- Explain the "what" and "why" (not "how")
44+- Use bullet points when appropriate (- or *)
45+- Wrap text at ~72 characters
46+- Reference issues and user stories when applicable
47+
48+## Footer Guidelines
49+- Reference issues with "Fixes #123" or "Closes #123"
50+- Breaking changes should be noted with "BREAKING CHANGE:"
51+
52+## Examples
53+
54+```
55+feat: Add user authentication system
56+
57+Implement JWT-based authentication flow with refresh tokens.
58+- Add login/logout endpoints
59+- Create token generation service
60+- Add middleware for protected routes
61+
62+Closes #45
63+```
64+
65+```
66+fix: Prevent race condition in database connection pool
67+
68+When multiple requests arrived simultaneously during
69+initialization, connections were being created beyond
70+the configured maximum. Added mutex lock to ensure
71+proper counting.
72+
73+Fixes #123
74+```
75+
76+```
77+docs: Update API documentation with authentication examples
78+
79+Add code samples for all authentication flows and
80+improve explanations of token usage.
81+```
82+
83+## Additional Guidelines
84+- When possible, limit commits to a single logical change
85+- Small, focused commits are easier to understand and review
86+- Avoid mixing multiple unrelated changes in a single commit
87+- When incorporating feedback from PR reviews, reference the PR number
