On Building Git for Lawyers

Perceived Need for “Git for Lawyers”

• Many lawyers and ex-lawyers report painful experiences tracking changes in large contracts, especially with multiple parties and adversarial counterparts.
• Problems cited: parallel drafts, hidden or undisclosed changes, manual merge errors, difficulty seeing a clean delta, and slow handling of big documents.
• Some engineers and clients reviewing legal docs also find Word-based workflows miserable and wish for clearer, linear history and better review UX.

Why DOCX and Word Remain Dominant

• Strong network lock‑in: everyone else expects DOCX with Word’s tracked changes; sending anything else is seen as unprofessional.
• Previous attempts requiring counterparties to join a new platform failed because onboarding “the other side” is too high a barrier.
• Backward compatibility with existing Word-centric workflows is viewed as essential; some tools position themselves as working even if only one side uses them.

Views on Word’s Track Changes and Versioning

• Critics: slow on large docs, noisy diffs (especially formatting and renumbering), fragmented history across files, and risk of leaking internal comments.
• Defenders (including experienced lawyers): Word’s tools are “good enough,” support legally meaningful formatting/citations, and the marginal benefit of new tools rarely justifies cost and training.
• Several note that proper use (e.g., cross-references, document-scrubbing tools) is underutilized but mitigates some issues.

User Needs vs Developer Mindset

• Repeated theme: developers over‑design programmer-style solutions (branches, Git UIs, LaTeX, DSLs, formal verification) that don’t match how lawyers work.
• Users often want a “toaster”: simple UI, minimal concepts, seamless integration into existing habits.
• There is debate over whether users mis-specify their own needs or whether developers fail at requirements gathering; most agree communication is hard.

Adoption Barriers and Incentives in Law

• Cultural inertia: law firms are conservative, some partners still work on paper; moving from WordPerfect to Word was already hard.
• Business model issues: menial document work trains juniors and is billable; some argue reducing it is not always in firms’ short‑term interest, others counter that error reduction and capacity gains still matter.
• A counter‑trend is noted: younger, more tech‑friendly partners and rising legal‑tech budgets.

Alternatives and Technical Approaches

• Suggestions: custom diff engines over DOCX, exporting/importing clean Word redlines, Git backends with text-conversion filters, or new VCS backends like jj.
• Skepticism that anyone can fully solve DOCX compatibility given long‑standing issues even for Google Docs and LibreOffice.
• Some argue truly robust solutions require deeply understanding and re‑implementing Word’s behavior, a very hard engineering problem.

“Git for X” Beyond Law

• Similar versioning pain reported in finance, engineering specs, construction change orders, medical device documentation, and personal note‑taking.
• Many commenters doubt Git’s CLI model will ever be widely adopted outside tech; domain‑specific, highly simplified UIs on top of version control are seen as more plausible.