rulesync/log/25/10/04 Sat - Issues with gitignore

• 2025-10-04 Sat - git/.gitignore issues

  • Yesterday I discovered that the rulesync/gitignore command implies a usage of rulesync in which the configuration files for any given tool are treated as compiled build artifacts. I was curious about trying out this workflow, so I ran it, which added a bunch of rules to .gitignore for each AI/Coding/Tool - CursorAI, Claude/Code, etc.
  • Today, on another computer I discovered the classic problem with introducing git/.gitignore rules after some subset of files have been tracked to the repo. I asked Claude Code about it.

    • AI/Response

      • The .gitignore patterns (lines 24-25 and 29-31) will only prevent untracked files from being added, but they don't affect files that are already in the git repository.
      • Here's what happened:
        • 1. These files were previously committed to your repository
        • 2. When you ran rulesync generate, it modified these already-tracked files
        • 3. Git shows them as modified because they're already being tracked
        • 4. The .gitignore patterns don't apply to files already in git's tracking
      • To fix this, you have two options:
        • Option 1: Remove these files from git tracking (recommended if you want rulesync to manage them independently):
          • git rm --cached .cursor/rules/*.mdc .github/instructions/*.instructions.md CLAUDE.md .claude/memories/*.md
        • Option 2: Keep them tracked and commit the changes (if you want these in version control):
          • `git add .cursor/rules/ .github/instructions/ CLAUDE.md .claude/memories/

            git commit -m "chore: update generated AI tool rules"`
            

    • So, what do I want to do?

      • Option 1 - Remove AI configuration files in repo

        • Pros

          • Some Search tools (like PyCharm) can respect git/.gitignore, and it would be convenient to not pollute the search space with a bunch of duplicate information.
          • It will be clearer to AI coding tools that respect gitignore which are the "canonical" versions of the files, which will be particularly useful in the common use case of asking AI tools to updating AI rules files.

        • Cons

          • Sometimes when I talk to people about how I accomplish certain things with AI, it's helpful to be able to hyperlink them to the exact prompt I use, and for many, it would be less confusing if that rule were in the format that they know.
          • I have to regenerate them regularly, which implies running them in a post-checkout hook.

      • Option 2 - Keep AI configuration files in repo

        • Pros

          • No need to regenerate them each time; one would regenerate every time a rule is updated, and then commit the changes
          • I can refer coders (be they human or AI) to a file in github that has the version of my rule in their framework of choice.

        • Cons

          • Often times I update AI configuration files in the middle of a task. Explaining to AI how to carefully stage only the items related to an AI configuration change when the git stage is dirty might be tricky and unreliable.
    • I ended up filing rulesync/GitHub/Issue/25/10/Feature request rulesync githook