Version Control and Developer Tooling Questions

Direct answer

Write a POSIX sh script at .git/hooks/pre-commit that inspects the staged (index) version of each changed file for trailing whitespace, and exits non-zero to block the commit if it finds any, or 0 to allow it.

Structured elaboration

#!/bin/sh
# .git/hooks/pre-commit
# Reject commits that introduce trailing whitespace in staged files.
offenders=""
for f in $(git diff --cached --name-only --diff-filter=ACM); do
  # skip binary files: test the STAGED CONTENT itself for binary-ness, not
  # the diff summary (which is always plain text even for a binary file, so
  # testing it here can never actually detect one).
  if ! git show ":$f" | grep -Iq . ; then
    continue
  fi
  if git show ":$f" | grep -nE ' +$' > /tmp/tw_hits.$$; then
    if [ -s /tmp/tw_hits.$$ ]; then
      offenders="$offenders $f"
    fi
  fi
  rm -f /tmp/tw_hits.$$
done

if [ -n "$offenders" ]; then
  echo "pre-commit: trailing whitespace found in:$offenders"
  echo "Fix with your editor's trim-on-save, or: sed -i 's/[ \t]*$//' <file>"
  exit 1
fi
exit 0

Install it:

chmod +x .git/hooks/pre-commit

Git only runs hooks that are executable; without chmod +x the file sits there silently doing nothing, no error, which is a common first-try trap.

Key points:

• git diff --cached --name-only --diff-filter=ACM: lists the STAGED files, filtered to Added, Copied, Modified, so a deleted file is not checked against content that no longer exists.
• git show ":$f": reads the file's content as it exists in the index (staged), not on disk. That matters if you staged part of a file and then made further unstaged edits, the hook should judge what is actually about to be committed.
• grep -Iq .: a quick binary-file detector; -I makes grep treat binaries as non-matching, so this check answers "does this file have any text content at all." It has to run on git show ":$f", the actual staged blob, not on git diff --cached -- "$f": git's diff output for a binary file is itself the plain-text line Binary files a/... and b/... differ, so piping the diff through grep -Iq . always finds text and would never skip anything, that was the bug in an earlier version of this hook until I actually staged a binary file and watched it get flagged.
• grep -nE ' +$': finds lines ending in one or more spaces (trailing whitespace); -n prints line numbers.

Worked example

$ git init -q && cd repo1
$ printf 'line one\nline two   \n' > bad.txt   # trailing spaces on line 2
$ git add bad.txt
$ git commit -m "test bad"
pre-commit: trailing whitespace found in: bad.txt
Fix with your editor's trim-on-save, or: sed -i 's/[ \t]*$//' <file>
$ echo $?
1

$ printf 'line one\nline two\n' > bad.txt      # whitespace removed
$ git add bad.txt
$ git commit -m "test good"
[main (root-commit) 4aa9153] test good
 1 file changed, 2 insertions(+)
$ echo $?
0

This was run exactly as shown: the first commit is blocked and exits 1, the second, after fixing the whitespace, succeeds and exits 0.

A third case exercises the binary-skip path specifically, since that's the part most likely to silently regress:

$ head -c 200 /dev/urandom > bin.dat
$ git add bin.dat
$ git commit -m "add random binary"
[main eaeaa2f] add random binary
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bin.dat
$ echo $?
0

A random 200-byte binary blob commits cleanly, exit 0, confirming the skip check is reading the staged content itself (which contains NUL bytes) rather than the always-textual diff summary.

Complexity & edge cases

• Complexity: one git diff to list staged files, then one grep pass per staged file, proportional to the number of staged files times their size. Fine for a normal commit; a commit that stages an unusually large generated file would benefit from a size cutoff before running the whitespace scan on it.
• Skipping binary files is what the grep -Iq . check does, but only when it's run against the staged blob content (git show ":$f"); without it, or if it's accidentally run against the diff summary instead of the content, a staged binary can trip a false positive trying to text-match inside it.
• Running fast on large repos: this hook only ever looks at STAGED files, not the whole repository, so its cost scales with the size of a single commit, not with repo size, that is inherent to the design. A separate, heavier full-repo scan run as a CI gate is a different concern from the local hook's speed.
• Hooks live in .git/hooks/, which is NOT tracked by git itself (it lives inside the local .git directory), so this script must be distributed separately, either through a setup script that copies or symlinks it into place during onboarding, or a framework like pre-commit or husky that manages hook installation and versions the hook definitions inside the repository proper.

Direct answer

Rewriting git history removes the secret from future clones, but it does not undo the fact that it was already exposed, so the first move is to treat the key as compromised and rotate it immediately, in parallel with, not waiting for, the history rewrite. Then rewrite history with git filter-repo (the current recommended tool for this; BFG Repo-Cleaner is a faster, narrower alternative for simple file or pattern removal, and the legacy git filter-branch is slow enough on real repositories that neither tool's own maintainers recommend it anymore), and treat the rewritten history as a breaking change that every contributor and every CI runner must adopt through a coordinated, communicated cutover, not discover on their own.

Structured elaboration

1. Rotate first. Revoke the exposed API key at the provider and issue a replacement immediately, then update it everywhere it's consumed (CI secrets store, deployed services). This step does not depend on the git cleanup finishing, and should not wait for it, because anyone who already cloned the repo, or any bot scraping public commits, already has the old key.

2. Prepare and test the rewrite on a throwaway copy, not the live repo:

git clone --mirror git@example.com:org/repo.git repo-rewrite.git
cd repo-rewrite.git
git filter-repo --path secrets/creds.json --path-glob '*.pem' --invert-paths --strip-blobs-bigger-than 10M

--invert-paths here means "remove these paths from history, keep everything else"; --strip-blobs-bigger-than clears out any oversized binary blobs in the same pass. Run this against a mirror clone (which includes every ref, not just the default branch), since that's what you'll eventually push back to replace the canonical repo.

3. Verify before touching the shared remote. Grep the rewritten history for the secret pattern to confirm it's actually gone, and run git fsck to confirm the rewritten repository is structurally sound.

4. Communicate the cutover window in advance. Announce the exact time, that main will briefly go read-only, and the exact re-clone command everyone should run afterward, ideally 24 to 48 hours ahead plus a reminder right before.

5. Cut over. Make the canonical remote briefly read-only, push the rewritten history to replace it, then reopen it:

git push --force --mirror git@example.com:org/repo.git

6. Coordinate re-clone. Rewriting history changes every commit hash from the affected commit onward, so old clones are not compatible with a simple git pull. Every contributor should re-clone fresh, the safest option:

git clone git@example.com:org/repo.git

For CI, purge any cached workspace or checkout the runners keep between jobs, and force a fresh clone on the next run, so no runner is quietly still building off pre-rewrite history.

The everyday commands these steps build on

A couple of the underlying moves here are also useful on their own, in much lower-stakes situations. Creating a feature branch and pushing it:

git checkout -b feature/my-change
git push -u origin feature/my-change

Undoing a commit you made locally, but haven't pushed yet, while keeping the changes:

git reset --soft HEAD~1     # keeps changes staged
git reset --mixed HEAD~1    # the default; keeps changes, but unstaged

Neither of those touches shared history the way the secret-removal rewrite above does, which is exactly why that rewrite needs so much more ceremony (mirroring, verification, a communicated cutover) wrapped around it.

Trade-offs and pitfalls

A rewritten history invalidates any open pull requests based on old commits, they'll show a huge, confusing diff against the new history, and it breaks external references to old commit hashes, like issue links or deploy tags. Forks are a real gap: anyone with a fork, or an old local clone nobody remembers exists, can still have the secret in their own copy, which is exactly why rotating the key is not optional even once the rewrite looks clean. git push --force --mirror overwrites every branch and tag on the remote at once, so verifying on a mirror clone first is not optional either; a mistaken filter-repo invocation run directly against the canonical remote can silently drop history you meant to keep.

Direct answer

Use git svn (Git's built-in bridge to Subversion) to replay the full SVN revision history into equivalent git commits, map SVN's trunk/branches/tags directory convention onto git's native branches and tags during that conversion, strip large binaries out of the resulting history with a history-rewriting tool before anyone starts working off it, and roll out with a short, clearly communicated cutover plus hands-on developer training.

Structured elaboration

• Tooling and approach: git svn clone (with --stdlayout if the SVN repository follows the conventional trunk/branches/tags layout, or explicit --trunk/--branches/--tags paths if it does not) walks the entire SVN revision history and creates equivalent git commits, preserving authorship and commit messages. That is what makes it history-preserving rather than a fresh start that discards the past. git svn replays every revision, so it can be slow on a very large or long-lived repository; svn-all-fast-export is a faster alternative some large-scale migrations use for the same purpose.
• Mapping branches and tags: SVN represents branches and tags as ordinary directory copies under branches/ and tags/ by convention, there is no first-class distinction the way git has. The --stdlayout option understands this convention and converts SVN branch directories into real git branches and tag directories into real git tags automatically. A non-standard SVN layout needs the mapping specified explicitly, or fixed up as a follow-up cleanup pass.
• Large binaries: SVN repositories that grew over years often accumulated large binaries, build artifacts, media files, directly in history. If carried forward verbatim, the resulting .git directory can balloon and every clone gets slow. Identify large blobs in the converted history (git-sizer or inspecting the pack directly can find them), strip them out with git filter-repo (the current recommended tool, replacing the older and now-discouraged git filter-branch), and going forward put anything genuinely needing versioning-by-reference, like build artifacts, into Git LFS (Large File Storage, an extension that stores large files outside the main history) instead of the main history.
• Rollout with minimal disruption: freeze the SVN repository to read-only from the moment the git conversion is finalized, so no new commits land in SVN after the point your git history was generated from, avoiding a second, harder-to-reconcile conversion later. Pick a single, short, clearly communicated cutover window rather than a long ambiguous transition, that matters more than getting every developer moved on day one.
• Developer training and rollout communication: a working git mirror is necessary but not sufficient. Most real friction comes from developers who know SVN well but not git's mental model, the staging area, local commits before a push, rebasing. Run a short hands-on session covering the SVN-to-git command equivalents the team will use daily (svn update becomes git pull, svn commit becomes git commit plus git push, svn revert becomes git checkout/git restore), publish a one-page cheat sheet, and designate a couple of developers who migrated early as "git buddies" who can answer day-to-day questions during the first few weeks, rather than relying on documentation alone.

Worked example

This is a conceptual walkthrough of the migration steps, not an executed transcript.

1. git svn clone --stdlayout --authors-file=authors.txt https://svn.example.com/repo git-migration converts the full history; authors.txt maps SVN usernames to proper "Name <email>" git identities so history is not attributed to raw SVN logins.
2. Run git-sizer (or inspect .git size directly) against the result to find oversized blobs from history.
3. git filter-repo --strip-blobs-bigger-than 10M (or a targeted path exclusion for known binary directories) removes the identified large files from history.
4. Push the cleaned history to the new git host, and verify branches and tags mapped correctly against the original SVN layout.
5. Freeze the SVN repository to read-only, announce the cutover date at least a week ahead, run the training session, and staff a couple of git buddies for the first two weeks post-cutover.

Trade-offs & pitfalls

• git svn preserves history at the cost of migration speed; expect it to take meaningfully longer than a shallow or fresh conversion on a repository with years of revisions, budget time for it rather than treating it as instantaneous.
• Stripping large binaries from history is a one-way, history-rewriting operation, every commit hash changes. It has to happen BEFORE anyone starts working off the new git history, not after, or the team ends up fractured across two incompatible histories.
• Underinvesting in the training and communication step is the single most common way an otherwise-correct technical migration still fails in practice. Correct tooling does not matter if half the team is quietly still working in SVN because nobody walked them through the new daily workflow.

Direct answer

Use grep -ci 'error' /var/log/app.log for a count, and grep -in -C 3 'error' /var/log/app.log to show each match with 3 lines of context before and after, both case-insensitive.

Structured elaboration

# how many matching LINES contain "error" (case-insensitive)
grep -ci 'error' /var/log/app.log

# show each match with 3 lines of context before and after, with line numbers
grep -in -C 3 'error' /var/log/app.log

Key points:

• -i: case-insensitive, matches ERROR, error, and Error alike.
• -c: prints a single number, the count of matching lines, not the count of occurrences.
• -C 3: 3 lines of context both before and after each match (equivalent to combining -A 3 and -B 3).
• -n: prefixes each printed line with its line number. Matched lines are marked with :, context lines with -, which is how you tell a real match from surrounding context in the output.

Worked example

$ cat app.log
2026-08-10 10:00:01 INFO starting service
2026-08-10 10:00:02 INFO connected to db
2026-08-10 10:00:03 error timeout connecting to cache
2026-08-10 10:00:04 INFO retrying
2026-08-10 10:00:05 INFO retry succeeded
2026-08-10 10:00:06 ERROR failed to write to disk
2026-08-10 10:00:07 INFO cleanup
2026-08-10 10:00:08 INFO shutdown requested

$ grep -ci 'error' app.log
2

$ grep -in -C 3 'error' app.log
1-2026-08-10 10:00:01 INFO starting service
2-2026-08-10 10:00:02 INFO connected to db
3:2026-08-10 10:00:03 error timeout connecting to cache
4-2026-08-10 10:00:04 INFO retrying
5-2026-08-10 10:00:05 INFO retry succeeded
6:2026-08-10 10:00:06 ERROR failed to write to disk
7-2026-08-10 10:00:07 INFO cleanup
8-2026-08-10 10:00:08 INFO shutdown requested

This was run exactly as shown. Notice the two matches (lines 3 and 6) are only 3 lines apart, so their ±3-line context windows overlap and grep prints one continuous 8-line block rather than two separate excerpts.

Trade-offs & pitfalls

• Complexity is a single linear pass over the file, proportional to file size. Fine as a one-off on a large log; a very hot, repeated version of this query is where you would reach for a log aggregator instead of re-running grep constantly.
• -c counts matching lines, not occurrences: a line containing "error" twice still counts once. To count actual occurrences, use grep -oi 'error' app.log | wc -l.
• If the log contains stray binary-looking bytes (for example from a crashed writer), grep may report "binary file matches" instead of printing the lines. Force text handling with grep -a.

Direct answer

List available signals with kill -l, read their full semantics with man 7 signal (Linux) or man signal (BSD and macOS), and read the kill command's own syntax with man kill. Always try SIGTERM first and give the process a bounded grace period to shut down cleanly; escalate to SIGKILL only if it ignores SIGTERM and is still running after that window, since SIGKILL cannot be caught or ignored and skips any cleanup the process would otherwise perform.

Structured elaboration

Discovery commands:

kill -l      # list available signal names
man 7 signal  # Linux: full semantics of every signal
man kill      # semantics of the kill command, including -s/-SIGNAME syntax

• Why SIGTERM first: it is the "please shut down" signal. A well-behaved process can install a handler for it, finish in-flight requests, close file handles and database connections, and exit on its own terms.
• Why SIGKILL only as a last resort: the kernel terminates the process immediately. No handler runs, no cleanup happens, and anything the process would have flushed (temp files, half-written state, an open transaction) is simply abandoned.
• Decision criteria in production: send SIGTERM, wait a bounded grace period sized to the service (long enough to drain in-flight work, short enough not to stall an incident response), check whether the process actually exited, and only send SIGKILL if it is still alive after that window. This is exactly the escalation most process supervisors implement natively (systemd, Docker, Kubernetes all send SIGTERM, wait a configured grace period, then SIGKILL).

Worked example

$ kill -l
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH INFO USR1 USR2

This was run on macOS (BSD). On a typical Linux distribution, kill -l instead prints a numbered list (1) SIGHUP 2) SIGINT ... 15) SIGTERM ...) and additionally shows the SIGRTMIN through SIGRTMAX real-time signal range that BSD does not have. The signal names and the SIGTERM-then-SIGKILL decision logic are identical on both; only the exact numbering and list differ.

Trade-offs & pitfalls

• Jumping straight to SIGKILL because it "just works faster" is the most common production mistake: it can corrupt in-progress writes and orphan child processes or open sockets that the OS then has to clean up on its own schedule.
• killall (or pkill) matches by process name across the whole host, not by the specific PID you intend to target. killall java on a shared host kills every JVM process it can see, including ones owned by an unrelated service. Confirm the exact target first with ps aux | grep <name> or pgrep -a <name>, and prefer signalling by PID (kill -TERM <pid>) once you have verified it is the right process. If you must match by name, scope it as tightly as the tool allows, for example pkill -f 'exact/path/to/binary --exact-flag'.
• Some processes ignore SIGTERM entirely, by design or by bug. That is the specific case SIGKILL exists for, not a default you reach for out of impatience.