Popular Git config options

Original Article ↗ Hacker News Discussion ↗

Power users of Git trade their favorite configuration tweaks, from `rebase.autosquash` with “fixup” aliases and `rerere` for smoother rebases to smarter diffs (`delta`, `difftastic`, diff3-style conflict markers) and customized editors and mergetools. Many emphasize workflow and safety improvements—such as enforcing LF line endings, better branch and alias management, or per-repo identities—arguing these small settings dramatically reduce friction and mistakes. A substantial side debate centers on the default branch name change from `master` to `main`, highlighting how seemingly simple defaults can create real compatibility and cultural tensions across tools and teams.

Rebase workflows & conflict handling

  • Several commenters praise rerere for rebase-heavy workflows, but warn that a bad recorded resolution can “poison” the cache and make large rebases painful.
  • rebase.autosquash plus a fixup alias is described as a major productivity booster for cleaning history via --fixup commits.
  • Many think pull.rebase or pull.ff=only should have been defaults, arguing merge-commits from git pull confuse newcomers.
  • People strongly recommend changing merge.conflictstyle from the default to diff3 (or variants like kdiff3/zdiff3), saying the default conflict markers don’t give enough context.

Aliases & workflow shortcuts

  • Numerous alias collections are shared: shortened commands (co, st, lg, hist), pretty log graphs, “cheese-touch” (last editor via log), praise = blame, and scripts using fzf to fuzzy-pick branches.
  • Aliases to always check out the repo’s default branch (using origin/HEAD) are suggested to cope with differing main-branch names.
  • Some prefer shell aliases (e.g., gs, gl, gd) over Git aliases for frequently used commands.

Default branch naming (master/main/trunk)

  • The init.defaultBranch option sparks a long debate.
  • One camp keeps master for consistency and minimal disruption, and sees renaming as politically driven and costly (tooling assumptions, mixed repos, outages).
  • Another camp adopts main (or trunk) because Git and GitHub nudge that way, it avoids nag messages, is shorter to type, and reduces potential offense; they view the name as arbitrary and argue tools should not hard-code it.
  • Some report significant operational pain from mass renames; others argue the real bug was tools assuming master.

Editors & commit messages

  • core.editor vs EDITOR env var are both used; some prefer lightweight editors like nano -t to avoid Vim’s modality, others tout Vim/Neovim keybindings (ZZ, ZQ, :cq) as very efficient once learned.

Identities, remotes & ssh

  • Multiple strategies for work/personal emails: includeIf gitdir:, user.useConfigOnly with per-repo user.email, or separate OS users/containers.
  • insteadOf mappings and ~/.ssh/config tricks shorten GitHub/remote URLs and attach specific keys per host; some enforce IdentitiesOnly yes to avoid cycling through all keys.

Diff/merge tools & output

  • Many use external tools (difftastic, P4Merge, kdiff3, meld, delta) via diff.tool, difftool, and pager settings for better, syntax-aware diffs.
  • Visual 3-way git mergetool UIs are recommended for conflict resolution, though some emphasize getting the underlying conflict marker style right.

Line endings & safety

  • core.autocrlf = input + safecrlf = true, or .gitattributes with eol=lf, are used to enforce LF-only text and avoid CRLF churn, even on Windows.
  • safe.directory=* and other advice-suppression knobs (e.g., advice.detachedHead=false) appear in shared configs.

Telemetry & popularity data

  • There is discussion about how to know which options are “popular.” Some see telemetry as valuable for discovering real usage patterns and UX problems; others remain wary or opposed, preferring opt-in metrics or indirect signals (stars, downloads) over built-in tracking.