| 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/save.mdc
@@ −1 @@
1---
2description:
3globs: src/game_engine/save/**
4alwaysApply: false
5---
6The save/load/rewind/replay/rollback subsystem collection needs to be robustly tested.
7
8We will use it for implementing the MTG card Shahrazad "Players play a Magic subgame, using their libraries as their decks. Each player who doesn't win the subgame loses half their life, rounded up."
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:
3−globs: src/game_engine/save/**
2+description: Git commit message guidelines
3+globs:
44 alwaysApply: false
55 ---
6−The save/load/rewind/replay/rollback subsystem collection needs to be robustly tested.
6+# Git Commit Message Guidelines
77
8−We will use it for implementing the MTG card Shahrazad "Players play a Magic subgame, using their libraries as their decks. Each player who doesn't win the subgame loses half their life, rounded up."
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
