How to commit with guard in place

Commits with the guard

1. The NEW: filename.ext (the guard reads it)

   • Every commit needs one. Nothing new: -m "NEW: none"
   • Name each NEW file the commit adds under brains/. The file name is enough, no path needed, any separator: -m "NEW: items-cache.js, foo.css"
   • New files outside brains/ (like _ADMIN docs) don't have to be named, but naming them is fine.

2. Splitting a long command over lines End each line except the last with \ and NOTHING after it, not even a space. Or keep it all on one line.

3. If the guard refuses: Read the reason.

   1. "'X' was deleted (tools/retired.txt)" means the NAME X is retired and is back in a file you're committing.

      retired.txt itself is fine. Usually it means something got staged that you didn't mean to commit.

4. NUCLEAR ONLY OPTION: ACCID_GUARD=off
   ACCID_GUARD=off git commit -m "what it does" -m "NEW: none" only use if the guard itself is wrong (most likely is not)

Basic Everyday

1. Don't use "git add ." (or git add -A) It stages every changed file in the folder you're in and below. From the repo root that's every change in the repo, including Codey's half-finished work and stray edits. /path/name.

2. The everyday habit

   git status                      # see what's changed
   git add <the files you mean>    # by name, or a folder: git add _ADMIN/prompts/
   git diff --cached --stat        # check what's actually going in
   git commit -m "what this commit does" -m "NEW: none"  # commit of what you stage and why  + guard NEW: check w/ no new files in brains.
   

A) If you only staged (added) what you mean, a plain git commit w/ the guard NEW: list is safe

but NO new files in brains you still have to declare that -m "NEW: none" NEW: ? is alwasy required.

If files are added in the "brains" folder those MUST to be listed or the guard will not allow the commit. Other new file names are not required but can be listed – you only need filenames, paths are not reiqured for NEW: .

git status                      # see what's changed

git add <only the files/folders you mean>    # by path/name, or a folder: git add _ADMIN/prompts/ 

git diff --cached --stat        # check what's actually going in you should only see the stuff you just added

git commit -m "what this commit does" -m "NEW: newfileinbrains.ext, newfile2fileinbrains.ext, newfilenotinbrains.ext" (new files in brains are required in brains - new files outside of brains are not required but are ok to add)

You do NOT have to list the paths to each file for NEW: only the filename works AND you can list filenames out side of brains if you choose to (keeps the log up to date).

B) AVOID THIS!! When other things are staged (added) that you DON'T want in this commit

you have to tell it what you WANT committed (by path/filename) so those files are commited and the rest is left only staged

git status                      # see what's changed

git add .                       # you added ALL changes but don't want to send all of them so you need to tell it which ones in the commit 

- OR - 

there is other stuff staged that isn't yours and you don't know what is on with it you see that here: 

git diff --cached --stat        # check what's actually going in - other staged pieces? - don't commit it 

git commit -m "what this commit does" -m "NEW: newfileinbrains.ext, newfile2fileinbrains.ext" -- path/newfileinbrains.ext path/newfile2fileinbrains.ext path/updatedfilethatwaschangedbutisnotnew.ext  (show paths to the files you WANT to commit - new and updated both)

— means "commit only these paths".

• List new and updated files by path/filname.ext with spaces, no commas.
• Paths are relative to the folder you're in (run from /var/www/starter).

A brand-new file must be git add-ed first. Everything else stays staged for later.

git add path/newfileinbrains.md path/newfile2fileinbrains path/updatedfilethatwaschangedbutisnotnew.md (also can add entire folder)
git commit -m "what this commit does" -m "NEW: newfileinbrains.ext, newfile2fileinbrains.ext" -- path/newfileinbrains.ext path/newfile2fileinbrains.ext path/updatedfilethatwaschangedbutisnotnew.ext  (show paths to the files you WANT to commit - new and updated both)

retired.txt

etired.txt lists names, not files. Each line is a pattern (a function, a global, a file name or a CSS prefix) with a status:

The guard’s output labels:

• BACK: a gone name is in code again. Refused.
• note: a gone name appears only in comments (stale comments). Reported, fine.
• LIVE: a kill name is still in code. Expected, e.g. AccidStylePanel 29.
• DONE: a kill name has 0 code lines left. Flip it to gone in the same commit that deleted it. From then on it can’t come back unnoticed.

Rules from the file itself: never delete a line, and comment lines don’t count as code. It doesn’t scan _JUNK, the old seeds, aug27test-accid, upload-to-live, vendor, *.min.js or *.md.

When the old-panel cleanup lands, those six kill lines (AccidStylePanel, accid-style-panel, BottomBarPanel, …) show DONE and become gone.

A correction to what I told you earlier. Reading the guard’s code, your refused commit probably did not have those four code files staged. Look at the first line of its output:

retired check — whole tree under brains/ (CI mode)

The guard falls into “CI mode” (scanning the whole tree) only when nothing is staged. With files staged, it would have said “N staged file(s) under brains/” or “touches no code under brains/”. So when you first ran git commit, nothing was staged. Your archive file hadn’t been added yet. The guard then scanned the whole tree, found the three names that really are back somewhere in the repo, and refused with “it is in a file this commit changes”. That last part was untrue. When you added the file and committed again, it said “touches no code under brains/”, which fits.

So you did nothing wrong. This is a guard bug: an empty commit on the box gets the whole-tree CI scan and blames old problems on your commit. The fix for Codey, small and in its own commit:

• In the pre-commit hook: nothing staged → say “nothing staged” and stop. Never CI mode.
• CI mode only when CI asks for it (an explicit flag or environment variable), not “because nothing is staged”.
• Reword the refusal: “the retired name ‘X’ is in “ — and only add “a file this commit changes” when that’s true.

The cheat sheet’s advice to stage by name still stands; it’s just not what caused this one.