Git commands I run before reading any code

Overall reaction to the commands

• Many find the git heuristics genuinely useful for quickly orienting in an unfamiliar repo, and several readers ran them on real codebases and got interesting insights.
• Others argue the conclusions are fragile: churn, “buggy” files, and activity graphs often don’t match what they know about their own projects.
• Several people say they’d never type these out raw; they’d turn them into aliases, scripts, or a single diagnostic command.

Jujutsu, Nix-like feel, and CLI complexity

• Some compare jujutsu’s revset/template language to jq or Nix: powerful, composable, but more “programmable” and less intuitive than simple shell + git.
• A few daily jj users say its model (especially for rebasing and conflict handling) is much nicer than git, but others bounced off it as overkill or incompatible with existing workflows and muscle memory.
• There’s a recurring theme of not wanting to “program the VCS” and preferring simple pipelines over embedded DSLs.

Validity of the suggested metrics

• “Most changed files”: often surfaces lockfiles, CI configs, localization, READMEs, and other high-churn but low-risk files; people stress filtering and context, or you’ll draw naïve conclusions and look foolish.
• Bug hotspot via commit-message regex is seen as noisy and project-specific; suggestions include better regexes, word boundaries, and awareness of domain-specific words (“rollback”, “debugger”).
• “Accelerating or dying” based on commit frequency is heavily contested: reduced commits might mean stability, not decay, especially for small, focused tools.
• Several note richer approaches (e.g., churn vs. complexity, linking to bug trackers, Google-style “bugspots”) are more informative.

Squash-merge and history shape

• Long, detailed subthread debates squash-merge vs preserving commits.
• Pro-squash: cleaner main history, PR as atomic unit, easier revert/cherry-pick, works well with GitHub’s review UX, hides noisy WIP commits.
• Anti-squash: loses useful granularity for bisecting and archeology, compresses authorship, and reflects “people don’t know git” more than good process.

Commit messages and culture

• Strong divide: some insist on meaningful commit/PR descriptions and see bad messages as a leadership and culture failure; others consider detailed messages low value versus code and tickets.
• Squash workflows often rely on PR titles/bodies as the real “history,” making individual commit messages less important.

Tools, aliases, and AI

• Many use helpers like lazygit, magit, tldr, cheat.sh, navi, ArcheoloGit, or custom aliases/scripts instead of remembering complex invocations.
• Several lean on LLMs (local or cloud) to generate commands, diffs, and commit messages, reducing the need to memorize flags or DSLs.

Meta: “AI slop” suspicion

• Multiple commenters think the blog post’s tone and structure resemble LLM-generated “clickbait,” while others push back that such accusations are becoming reflexive and unhelpful.