Git tips and tricks

Original Article ↗ Hacker News Discussion ↗

Advanced Git features for large repositories, history rewriting and blame management are drawing renewed interest as core Git, GitHub and third‑party tools evolve. Commenters trade practical tips (aliases, external diff tools, `reflog`, `--force-with-lease`, blame ignore files) while debating whether developers should embrace Git’s power or hide behind simpler GUIs and porcelain. Underneath is a broader question of ergonomics versus capability: Git’s plumbing is praised as conceptually elegant yet its user interface is seen as leaky, prompting calls for better frontends, alternative VCSs, and more approachable documentation.

Overall reaction to the article/talk

  • Many commenters found the tips and the associated talk highly informative and entertaining, even for experienced Git users.
  • Several people credit the author’s previous Git documentation with shaping how they understand Git.
  • Some suggest additions: mention .git-blame-ignore-revs, --force-if-includes, and more detail on history simplification and diff/patch-based operations (e.g., rebase).

Git complexity, learning curve, and expectations

  • A recurring theme is tension between “I just want push/pull” and “engineers should understand more,” especially reflog and basic history rewriting to avoid disasters.
  • Several argue Git is inherently complex because the underlying problem is complex; others counter that Git’s porcelain is poorly designed and violates KISS, pointing to Mercurial or pijul as cleaner designs.
  • Git is often described as originally “plumbing” with minimal UI, which explains its rough edges and leaky abstractions.

CLI vs GUI and how people actually use Git

  • Some proudly stick to the CLI for speed, scriptability, and portability (e.g., SSH to servers).
  • Others strongly prefer visual tools (GitKraken, SmartGit, TortoiseGit, IDE integrations) for graphs, diffs, conflict resolution, and reflog inspection, using CLI only for special cases.
  • A middle ground: use GUI for visualization/diffs and CLI for core operations and advanced fixes.

Conceptual models: snapshots vs diffs

  • Discussion around rebasing, cherry-picking, and merges: people stress that although Git stores snapshots, these operations conceptually operate on diffs/3-way merges.
  • Some report that teaching Git as “diff-based operations over a snapshot store” makes rebase behavior more intuitive.

Tools, aliases, and extensions

  • Many tips shared: external diff tools (difftastic, delta), navigation helpers (git root, zoxide), branch cleanup (git gone), fuzzy-add workflows, and custom “sync/publish/PR” aliases.
  • Git “porcelain via scripts” pattern: git-foo scripts on PATH invoked as git foo.
  • Extra utilities praised: git-extras, git-absorb, “git attic,” and a script that blames all commits in a file.

Large repos, performance, and maintenance

  • Interest in large-repo features (fsmonitor, maintenance, Microsoft/GitHub contributions) and Git LFS integration; unclear if LFS will ever be “core.”
  • Questions and partial answers about git maintenance, garbage collection timing, and worries about losing loose objects.
  • Pain points around cloning huge monorepos over unreliable connections; desire for resumable clone/fetch behavior.