You already have a Git server

Original Article ↗ Hacker News Discussion ↗

Basic Idea: Git over SSH and Local Paths

  • Many commenters note that any SSH-accessible machine (or even a plain directory / NFS share) can act as a Git “server”; no special Git daemon or forge is required.
  • Several admit they’d used Git for years without realizing SSH alone suffices, often because they assumed a dedicated Git server was needed.
  • Others point out you can also push/pull via local paths (/path/to/repo, file:///…) or shared drives.

Bare vs Non‑Bare Repositories

  • Strong consensus that a central repo should usually be git init --bare, avoiding the “can’t push to checked-out branch” problem and worktree conflicts.
  • The article’s receive.denyCurrentBranch=updateInstead approach is criticized as brittle and only safe for narrow single-user workflows.
  • Bare repos are promoted for USB sticks, shared NFS mounts, and as central hubs with hooks that update a working tree or trigger deployments.

Git as Distributed, vs GitHub as Centralized

  • Many stress that Git was designed as a distributed VCS where any clone can be a remote; you can pull from coworkers’ machines, pendrives, or local “hub” repos.
  • There’s concern that newer developers equate “git = GitHub” and never learn offline or peer‑to‑peer workflows.
  • Some see GitHub’s dominance as “centralizing” a decentralized tool, yet acknowledge its contribution in standardizing workflows and adding CI, issues, and UI.

Complexity, “Tribal Knowledge”, and Learning Curve

  • Debate over whether concepts like bare repos and SSH remotes are “fundamentals” or obscure details.
  • Critics argue Git’s UI is inconsistent, staging and bare/non‑bare distinctions are leaky abstractions, and docs are book‑length.
  • Others counter that understanding your tools is part of professional practice, and Git’s power justifies some learning; reflog and local copies make experimentation safe.

Self‑Hosting and Tooling

  • Lightweight self-hosting options discussed: gitolite, git-shell-only users, cgit for read‑only web views, git daemon, and bare repos synced via Syncthing.
  • Heavier forges like Forgejo/Gitea are valued when you also need CI/CD, package repos, and PR workflows; bare+hooks are preferred for simple personal use.
  • Some explore creative setups: etckeeper + git subtree to manage many machines, worktrees, multi-URL remotes, and hooks for tiny CI/deploy systems.

Practical Pitfalls and Security

  • Warnings about:
    • Syncing repos with Dropbox/OneDrive/iCloud leading to corruption.
    • Exposing .git via web roots leaking history and secrets.
    • Corporate rules (or confusion) blocking git installs or treating GitHub and git as the same.
    • Granting SSH access vs using more constrained mechanisms (git-shell, sftp chroots).