Git Things
Debate over everyday Git practices reveals deep disagreements about how much structure and discipline a healthy codebase requires. Commenters argue over commit message length and content, whether to keep “messy” intermediate commits or squash them, how to handle failing tests and refactors, and when rebasing or merging is appropriate. Underneath the tooling details is a broader tension between optimizing for fast, low-friction changes and preserving a clear, reliable history that aids reviews, debugging, and long-term maintenance.
Code review & workflow
- Some teams adopt “ship/show/ask” styles where the author chooses how much review is needed, enabling fast merges for small, low‑risk changes.
- Others argue reviewer choice should depend more on who understands the affected code, not solely author confidence.
- A proposal to “optimistically merge” to main and review afterward gets pushback: critics say it degrades main’s reliability, removes the social pressure to review, and deprives juniors of learning via feedback before merge.
- Documentation and tests often stall PRs; suggestions include treating docs as first‑class (PR not acceptable without them), writing docs first to clarify intent, or reviewers drafting initial docs to expose gaps.
Commit messages & history
- Strong disagreement about “minor”/“fix”‑style messages: some think they’re acceptable for tiny changes; others insist every commit must express intent, especially for blame/bisect debugging.
- Many want at least high‑level context in the subject (“what”), sometimes with a ticket ID; others argue the minimum should be “why,” since the diff already shows “what.”
- The 50‑character subject guideline is debated: some see it as archaic and driven by old terminals; others defend short subjects for skimmability in tools like
logandblame. Tools enforcing 50 chars are seen as irritating. - Squashing vs preserving granular commits: some prefer squashing to declutter; others argue you can simulate “squashed view” with
--first-parentand that squashing destroys useful history.
Tests, failing tests, and bisect
- Advice to commit a failing test first, then the fix, is praised as low‑friction TDD and helpful for review.
- Critics note it can break
git bisectand CI expectations if failing tests land on main. - A related suggestion to adjust assertions to lock in current wrong behavior (with TODO) is widely criticized; several argue tests should never enforce incorrect behavior and should instead be marked expected‑fail or removed.
Renames and history tracking
- Some see Git’s content‑based rename detection as a failure; they want explicit move metadata (
git mvrecorded robustly). - Others defend the current model, noting it enables tracking history across file splits/merges and fine‑grained moves, albeit imperfectly; flags like
git blame -Ccan help. - Proposals to add explicit move metadata raise concerns about complexity, tooling support, and merge conflicts.
Line length & tooling conventions
- Line/subject limits (80–120 for code, ~50–72 for commit subjects) are discussed as a mix of historical artifact and practical readability: side‑by‑side diffs, small laptops, aging eyes.
- Some argue for relaxed or no hard limits and letting tools wrap; others stress that shorter lines are easier to read and a soft limit also exposes overly complex expressions.
Branching: merge vs rebase
- Merge and rebase are seen as distinct tools: rebase for shared feature branches and history rewrites; merge for integrating work and preserving original commits.
- Some prefer merge commits as explicit places where conflict resolution lives; others rebase to avoid “dragon‑filled” merge commits and keep main linear for CI/bisect.