Hacker News Reader

Comment by durnygbur | Hacker News Reader

Why legal professionals are not using version control goddamit?! It's exactly the tool they need. Just recently worked with a lawyer who was negotiating settlement agreement on my behalf. The agreement in MS Word, edits highlighted with a color background, change requests in the body of the email - after 2-3 rounds of corrections reaching the other party nobody is able to keep a track of anything anymore. Seriously? Years of studies, prestigious profession, peoples' careers and lives at the stake, and this is how you work?!

View on HN

In a legal document negotiated between parties you don't want to keep track of every version of the file, just the latest version of the offered terms and counteroffered terms.

Changes by you are highlighted in one color.

Changes by other parties are highlighted in other colors.

If you need a diff between versions Word can generate one for you in seconds.

So yes, this is exactly how we work. Because it was designed to fit our workflow.

>In a legal document negotiated between parties you don't want to keep track of every version of the file, just the latest version of the offered terms and counteroffered terms.

Not true, at least from the point of view of a litigator.

The changes to an agreement can be crucial, especially in the absence of an entire agreement clause. There are, of course, rules about using evidence outside the agreement to construe its meaning, but many exceptions to this rule exist - eg, mistake. The biggest exception is ambiguity, where previous additions/deletions serve to highlight what the parties' intentions were at the time of agreement.

That would be awfully difficult to have accepted by a judge.

Even if it was, proving intent would be very difficult - after all just because you introduced a change doesn't mean I agreed to it.

Often contract clauses start off in a "no way I would sign that" state, and may get carried along for a while as you are focused on different things. The fact it existed in the history is, by itself, pretty meaningless.

As a former litigator, I have never found a judge willing to accept such evidence into the record.

i’d argue that it’s not “designed to fit our workflow” so much as designed around a subpar, but flexible tool that everyone was using. that don’t make it good; that just makes it ingrained

Track Changes tracks changes. By multiple authors. And allows comments outside of the substantive content of the document. It works across multiple versions of itself, and is even compatible with competing software. And best of all, it requires no additional software to learn or maintain.

That makes it superior for legal documents to all version tracking systems that I'm aware of that are used in the programming field.

Well yes, if you constrain the solution set to satisfy "requires no additional software to learn" then you'll end up with the status quo solution.

One thing I've always been concerned about when negotiating a legal agreement is how I verify that the tracked changes actually track every change. Because Word lets the user decide which changes to track, I'm always reading the untracked sections as well to confirm that no other changes were sneakily introduced. That's something that git addresses well. Does Word have a solution there? If not, does that ever concern you?

As a former attorney, I'd just do a diff. Save a copy, reject all changes, then do a diff and compare side by side. As a current software engineer, Word is definitely sufficient (and understood, which sf good) for two small adversarial teams. Key words being small (two huge firms negotiating a huge deal should not be using Word) and adversarial: I think a lot of times when tech-people suggest lawyers could do a better job they forget the other side isn't trying to be helpful.

Two huge firms negotiating a huge deal probably are in fact using Word, right?

Things like that probably have multiple outside counsel involved, and various versions of Word. :)

This is why you always do a diff.

In my limited experience, Word is used for the early back and forth, but final stages are done and reviewed in PDFs, and PDF diff tools used to identify any changes. No reason you couldn't do the same thing all in Word.

It does have such a tool, you would have rev A (old one) then collapse all the tracked changes in rev B and diff with A.

There is a Compare feature in Word exactly for use in these cases.

You say "requires no additional software", I say "doesn't allow me to use whatever software I want". For example, I can't edit a legal document while SSH'd into a host computer on my firms network.

Also, Track Changes doesn't allow two people to work on a document asynchronously, while git does.

I have seen a ridiculous number of errors in legal documents given the fact that a huge part of the legal profession is to produce solid/error-free documents.

But while the law profession's response to this seems to be just "be a better lawyer", the software industry's response is "build better tools that don't allow me to make errors". I'm sure I don't need to tell you which method I think is preferable in the long term.

I do not particularly agree with the some of the arguments made in this thread for and against the status quo, but some of your statements are factually incorrect.

>For example, I can't edit a legal document while SSH'd into a host computer on my firms network.

Track changes is supported by LibreOffice and its kin, so certainly possible to ssh into a computer on your firms network and edit it. Might require an X server on your local machine, I am not sure if libreoffice works in terminal (but its open source, so if you really wanted to you could add support!) That said, the recommended way to do what you are asking is to run an "Online Office Server", which gives you a online version of word (think google docs, but looks like MS word) that you can access through you VPN or company portal with ssl/tls. Different workflow for different folks I suppose.

>Also, Track Changes doesn't allow two people to work on a document asynchronously, while git does.

Office 2019 has added 'source control like' simultaneous/asynchronous editing when integrated with a Sharepoint server. Multiple people can have the file open, and the save button both commits your changes and pulls whatever other changes have been committed since, with options to resolve conflicts.

Furthermore, with the office 365 version of the office suite (or Online Office Server, which is nearly the same thing but self hosted) it is possible do live editing, whereby multiple people edit the same document simultaneously (google docs style). Not sure why you would want to do that, but it eliminates merge conflicts at least and seems to be pretty popular at my workplace. Especially useful when someone is presenting slides and there is something you don't like in them ;-)

Of course, as long as your document is on a sharepoint server, you get version control built in and can roll back to see the document at any save point, do diffs, etc.

It is true that the FOSS world is more civilized, but Microsoft isn't sitting by idly. They spent $8B on github for a reason, and it wasn't to get their business model.

Sorry, with the first point I wasn't very clear, but what I meant was editing a document from a SSH'd shell, using a CLI text editor like vim, emacs, nano, or any of the plethora of existing tools that work out of the box to edit documents. Editing which can then be checked into version control like git. That is obviously very different from "you can build a CLI for LibreOffice which is currently compatible with the Track Changes implemented by MS Office but might not always be".

Having to use MS Word in the cloud doesn't really scratch the itch I'm talking about either.

That's cool about Office 2019, I did indeed not know about that. Can I perform these Sharepoint-enabled changes while offline? It seems like all of the things you are talking about require a centralized online server in order to do. Regardless, I do not think there is a conflict between the statements "you need Sharepoint to do these things" and "Track Changes cannot do these things".

> a CLI text editor like vim, emacs, nano, or any of the plethora of existing tools that work out of the box to edit documents.

Asking a world that is used to what came out of Xerox PARC to switch back to 1970's technology on teletype emulators is...the only word I can think of is Quixotic.

The point is not that I want people to switch, it's that software developers have choice and lawyers / etc don't.

To write software, I can use a CLI text editor, a basic GUI text editor, an advanced text editor like Sublime or Atom or VS Code, or a full on IDE like the JetBrains products. I have so much choice, and all of these are interoperable with each other and have different places where they shine. All work with git. I just don't think the same thing can be said for the document-creation workflows around law and such.

A hammer is pretty much an ancient technology. A battery-powered plastic toy hammer, with buttons that play melodies, is a modern take. Yet serious people use the (modern implementations of) ancient-style hammer to drive nails.

That's my general response to "why use 1970s tech?", though I guess I'm being a bit unfair here. Word is, in some ways, a marvelous piece of engineering. The whole Office suite is. Unfortunately, thanks to path dependence and business strategies, it's also locked in a place where it's not interoperable with anything outside the Office ecosystem by default.

I guess I have an answer to the age-old question: in sci-fi shows, how come nobody in-universe notices their computing technology is, in many areas, ridiculously inefficient and ineffective compared to the old XX/early-XXI-century tech? The answer may be, the sci-fi future tech is built on so many layers of lowest-common-denominator, walled garden, non-interoperable tech that people no longer know how interoperability or efficient computing looks like.

I don't disagree a hammer is still a useful too, a lot like how a pencil and paper can still be a useful tool for architecting software, or when we need to sketch something out. However when it comes time to build a new construction, no, people are not out there hammering every individual nail. They're using nail guns and all manner of power tools to complete the job because it's more consistent and less time consuming.

Lol, claiming that using text files is somehow a regression is a pretty lame misdirection. You know what else came out of xerox parc? The GUI, the mouse, etc. You know what else is 1970s tech? The internet, databases, etc.

“Being old” is probably the lamest way to claim something shouldn’t be used.

You're asking for trouble if you are relying on track changes. Anyone can disable track changes, make changes without highlighting them and send it back with track changes reenabled. You need to compare any received file against what you last sent to see the real diff.

There's got to be a better way.

The better way is using the Compare feature that has been in Word for years, if not decades.

The problem with that is that it gives a change tracking tool that doesn't work, giving people a false sense of safety, relying on users to remember to manually diff every change sounds like a security issue in itself, that diffing should be either an automatic process instead of track changes or track changes should track everything by default.

If the other party attempts to sneak in such a change, usually you extract a concession from them when you catch them as many bar associations now regard that as unethical behavior warranting discipline.

Yes, but you still have to catch them, and the fact it's possible gives them the leeway to try, when the point of business is to do business, not to catch people out.

That's an imperfect solution for a problem that didn't need to exist in the first place that might even produce its own list of problems.

So if you have a set of documents that are all being negotiated at the same time between parties. How do you show what changed in DocumentA at the same time as the concessions in DocumentB? By comparing timestamps?

It feels like the CVS way of versioning (Every document has a history) rather than the modern way of versioning (A set of documents has a history).

Perhaps this is a smaller problem for these kinds of documents because while my changes are often a dozen changed documents in a set of a hundred thousand documents, these word processor changes are typically across one or two documents in a set of one to ten?

You don't have a set of documents. You just have the one document...

It's almost like you guys are deliberately ignoring all the lawyers with actual transactional experience to create hypothetical problems that don't exist in the real world so you can suggest version control as a solution.

No I realize the circumstances are different (like fewer documents in a process) but some times you don’t notice how your tools actually change your processes.

E.g: if you are in a process when there would naturally be two separate documents it may be that you are creating a single document becuse with the single document the change process works with the tooling.

Or is there something else inherent to the process that says a process/negotiation always includes one document?

I’m not sold on version control either - especially as structured text like word processors have such poor support - but it seems even change tracking in word documents should be able to track and show the differences in a set of documents such as a directory. I’m not arguing those tracking 3 word docs should use git.

Git has all those things, except yes it is a different tool.

Track changes in Word works pretty well for turns of a contract. What features do you think are provided by "version control" that aren't handled by Track Changes for contracts?

The ability to keep track of many, potentially thousands of individual changes and assign labels to significant versions. Track Changes is basically like Git if every file write triggered an automatic commit with no commit message and anyone could rewrite history at any time. SharePoint major versions are better but they’re not free, standard, portable or popular.

If you have a legal agreement with many thousands of changes at any point, someone is getting fired for royally fucking up...

Legal agreements are basically a war over each party's choice of standardized language followed by battles over customized terms.

That may be accurate for commercial contracts but lawyers write lots of other documents too, some of which are subject to thousands of edits. Think about judicial opinions, advices, written arguments, continuously updated legal commentary services, public reports, or indeed statutes. These documents are often carefully drafted over months and complex manual protocols get set up to manage it, due to the limitations of Track Changes and the lack of familiarity with the tools used by software engineers.

I agree. Most legal docs could probably be better captured in markdown or asciidoc rather than MS Word (and all the bloat it brings with it).

That’s the entire point of pull requests though? Or am I missing something

US Federal law works just like this but with an awful manual process that is screaming for a VCS:

- Laws are passed by Congress and signed by the President.

- The actual formal text of the law is printed in the “US Statues at Large”. Think of this like a commit log— it’s written as a series of add/modify/remove operations to the United States Code (USC), which represents the “master” branch of the repo; our current laws.

- Sometimes the add/edit/remove operations have implications in many parts of the code. There is a manually-intensive process that actually determines which parts of the USC must be modified and how. This is like code review on a PR.

- Periodically, after many laws are passed and many mods to the USC, it is “republished” (tag/release).

Why we couldn’t do this with our laws is beyond me. Institutional inertia I suppose.

Exactly parliamentary procedure was using content control well before computers where invented read Citrine or Roberts Rules.

But Executive's do get up to "naughty shit!" as a Uk Party Whip said to me once in a bar.

Most existing tools are written by coders for coders; they have diff engines and UIs built for plain-text source code, not human-readable rich text.

Word's "track changes" feature is good enough that an MVP for such a VCS product would need to have a very good UI.

(Source: talking about version control with a lawyer in the family.)

I use MS Office regularly and I would describe its interface as adequate for general use and infuriating for reading/writing formal documents. If that's the competition, I can't imagine it would be that expensive to develop an alternative (at least, not compared to what the US government current spends).

Why are legal documents recorded in a format that requires expensive software to access?

Why are LaTeX, Markdown, or HTML not sufficient formats? What makes plaintext not "human-readable"? I don't think anyone has trouble reading/writing their Facebook and Twitter posts in plaintext.

Why can't our government afford to develop a lawmaker-specific format and an editor (or plugin for an existing editor) to make it easy for lawmakers to work with?

Why can't our government afford to fund the creation of a VCS solution with a lawmaker-friendly interface and a public server to host the repository on?

Why can't all of our legal documents at least be hosted on a public server in their current state?

I'm guessing the answer to all of these is "because the public doesn't care enough, so it doesn't help anyone get re-elected and, therefore, there is no available funding". I have a hard enough time getting engineers to understand the value of good VCS, much less an average US citizen.

> Why are legal documents recorded in a format that requires expensive software to access?

Because lawyers can afford it, and don't really feel like expending effort evaluating software alternatives instead of just doing their work. And because of legacy/network effects. And because no one has pitched an alternative right for that audience.

> Because lawyers can afford it

Lawyers can afford free software too.

There's a reason that there is an “and” followed by a bunch of other things after the bit you quoted.

I have nothing to say about those points. I don't know enough to support or reject them.

It's clear what was meant was "cost is no object, so it's not an issue" - law firms probably pay more per-employee for things like travel expenses or coffee each year than for MS Office licenses.

I have seen that MS Office suite has become a hammer used to drive many non-nails in various businesses, and would like to see people using more open standards. But I totally understand that for many use cases it's good enough and that people consider the cost to be not particularly significant

edit: misplaced reply, moved to parent (too late to delete)

Ehhh ok? That’s kinda what I said

An individual business license of MS office 365 costs about 10 dollars a month per user. So even at minimum wage fully loaded costs this is approximately an hour. It's more like a minute or two for a lawyer.

Do you think having access to a tool with the least communication friction saves you 2 minutes/month of your lawyers time? 30 min of your junior marketing person? This isn't a hard call to make usually.

I'm more concerned about the people who are subject to the laws being written and (imo) deserve to be able to read them for free.

As for lawyers, just because they can afford to use expensive software doesn't mean they should. I can afford to write software in Word, but I don't plan to try that any time soon.

Also, I think people seriously overstate how "easy" it is to use Word. I have spent litteral days of my life in classes that taught me how to use Word. I have spent hours relearning MS Office interfaces as they've changed over the years. I'm pretty sure I picked up GitHub-flavored Markdown in less than 15 minutes.

Your first point is valid but quite separable, I think access is an important issue.

My point about the cost is that the network effects of the tool here are more important than the tool itself. You might be able to have a better local workflow using other tools, but if everyone you collaborate/work with doesn't use them then the cost of communication is far higher than any savings.

Realistically, legal work isn't much like coding. Although lawyers do spend time editing documents that isn't where the real time is. For that reason I'm not convinced that changing to a putative VCS workflow would have enough efficiency impact to pay for the training etc. except on a very long term. This sort of thing makes it very difficult to win out against network effects.

This is much the same reason that excel is used for a lot of things where better tools exist. The combination of network effects and having better things to do than learn a new approach and toolchain are hard to shift.

> Why are legal documents recorded in a format that requires expensive software to access?

Because the cost of the software is trivial compared to the cost of incompatibility or friction in communication.

Not for the citizens who just want to read the laws they're expected to follow.

Whose final form is probably PDF anyway. Even if it were .docx, there are lots of free softwares that can read or translate those.

So your real problem here is with the access to said laws, which is not a software problem.

Plain text wouldn't allow for annotations, TOC, references, etc. These get ignored more often than not but they're still requirements and some do use them properly. Something like latex would be better, but apparently it's too much to expect these highly educated lawyers to learn some basic markup.

I'd bet a tool like lyx (https://www.lyx.org/Screenshots) would go along way to being a better solution. It's a great document writer (as opposed to a word processor) and apparently has some VCS support (although I haven't tried this) and diff viewing and is a lot more reliable for annotations and all that stuff than word.

I've done some legal automation work before, it would have been so much easier (and get better results) to have a plaintext format we could manipulate with shell scripts than working with docx and word.

    - But doesn't plain text suck for difs?
    + But doesn't plain text suck for diffs?

    - Especially when you have a really long, multi-line
    - paragraph that has bmore than one change? And if we
    - relied on word wrap, then the scope of change would
    - be the paragraph and all hope is lost. At least 
    - this way we might eventually regain some 
    + Especially when you have an exceptionally long,
    + multi-line paragraph that has more than one change?
    + But if we relied on word wrap, then the scope of
    + change would be the paragraph and all hope is lost.
    + At least this way we might eventually regain some
      equivalency by chance and it's clear that nothing
      after that point has changed.

Git is great, but it's designed for code. Legal documents are probably structured more like code than any other prose with clear identified chunks and frequently breaking out into lists, but it's not the same thing.

(For clarity, I think probably a sentence-by-sentence diff would work well. But then it's not plain text; you're relying on some processor to collect sentences into paragraphs.)

Don't use plaintext, use LaTeX. Since paragraphs are separated by an empty line, you can have each sentence on a separate in a paragraph on a separate line and have it still formatted as a paragraph in the final document. This allows for better diffs. Here is an example:

https://github.com/dart-lang/language/blob/master/specificat...

> Don't use plaintext, use LaTeX

Markdown or Asciidoc has the same benefit as far as paragraphs.

Markdown doesn't address table of contents or references which were mentioned above.

Asciidoc does, and there are TOC tools for markdown, though they are add-ons to markdown processors.

The diff algorithm/display is orthogonal to the data format; for example, I use the --color-words option to the git tools to use a word-oriented diff everywhere. I've even seen plugins floating around online for visual image diffs in git!

But again, all those tools are built for developers, and especially the ones used by git for internal purposes like for conflict resolution make some strong assumptions that don't hold for prose.

SpringCM does just that.

https://www.springcm.com/products/contract-management/negoti...

> Why legal professionals are not using version control goddamit?!

For a start they’re using Word, which doesn’t work well with version control.

And asking most people to stop using MS Office is like asking them to go and live on the Moon, they look at you like you’re some kind of crazy person.

Word documents work well in version control. In case you're not aware, you can store word documents and do a diff between any 2 versions over git/svn on windows, it opens the diff view in Word.

You can store and diff them, but not merge them.

It's basically the same as using Word's own history features.

Wow, this is going to be very helpful for me. I had no idea. Thanks! So if I install git on Windows and do `git diff MyWordDoc.docx` in the command prompt it'll open up Word?

> You can also use the Git attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff.

First, you’ll use this technique to solve one of the most annoying problems known to humanity: version-controlling Microsoft Word documents. Everyone knows that Word is the most horrific editor around, but oddly, everyone still uses it.

...Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in .docx, it should run those files through the “word” filter, which is defined as the docx2txt program. This effectively makes nice text-based versions of your Word files before attempting to diff them.

https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...

I am using Tortoise. Not sure about the command line.

From direct knowledge of working with a State court system, I can tell you that WordPerfect is still very much alive and well!

Git is awesome.

But it's terminology is really confusing.

But yeah some layer of abstraction would be handy.

I always think of introducing it to my wife when she looses a document or something but god damn the terminology.

And if there's one thing that will deter lawyers, it's confusing terminology.

There are luddites and then there is the legal community.

I think we can get them on board. Need to rebrand some things with latin terminology, that's all. Let them file a petitio tracto instead of making a pull request.

https://gitless.com/

I think svn is a better way of thinking when working with documents, the fact that the timeline is contiguous too helps

you can easily have a contiguous git timeline if you want to

is a376f1 older or newer than 89fa2b?

The lack of continuous versioning is a problem for most document like workflows.

The commit message doesn't encode the timeline in neither git nor svn, and no-one complains.

So why do you expect the git hash to encode the timeline?

Git encodes the timeline in the parent/child relationship of commits (and/or the date stamps). Trying to look for the timeline information in the hashes is going to be futile, that's not where it's supposed to be found.

For documents that get send back and forth via email, amongst more than 2 participants, git's DAG is actually a better representation than a linear timeline.

(But yes, if you don't like that, you can set up git to reject commits with more than one parent to enforce a linear history.)

My advice to people who want history-tracking but don't know how to use a version-control system is: use Dropbox or OneDrive (I think Google Drive has something similar).

You get 30 days of history for every file in Dropbox (120 days for Business users). Earlier you could pay a bit extra to get a full year of history -- but that feature, called Extended Version History, is no longer available.

OneDrive unfortunately offers only 30 days, I believe Google Drive is similar.

Wonder if one can create a new repo and commit the revisions with original Authors' names and historical date.

That would make a lot of sense to folks who are unfamiliar with hit.... also me.

It's off topic but I seriously want Apple to use a VCS for their license agreements.

Every once in a while, they update Developer License Agreement or Paid Application Agreement (updated over 100 times so far), and every time they just show a wall of text. I save it as a file and take a diff to the previous version.

They must be using a VCS internally but they make us repeat the same effort again and again. It's stupid.

Maybe that's a start? Techies would find it easier to promote the use of proper VCS for legal documents if their products used them for their ToS, and exposed them to users, e.g. in form of diffs. There's even a precedent - Wikipedia uses such interface for all their pages, including their ToS - see https://foundation.wikimedia.org/w/index.php?title=Terms_of_....

Beyond technical hurdles that could be solved with a set of FLOSS components and plugins to popular CMSes, I don't see any reason not to do this if one runs a honest company.

The agreement in MS Word

Consider yourself lucky. There are still legions of legal documents in WordPerfect.

Nothing like receiving "red-lined" documents with revisions in the comments to make you want to scamper back to git-land.

Facepunch Studios Ltd (game dev studio) have their legal docs on GitHub: https://github.com/Facepunch/Legal

I agree, another problem with Word (and similar products) is it’s bloat in terms of formatting meta-data but also in glyph code-points. I often get strangely coded white-spaces or strangely coded non-ascii characters when using Word et. al. Legal documents should have limited formatting and strict encoded glyphs therefore a UTF-8 + git + markdown solution would be preferable over using Word. You can create easy to use WYSIWYG software that makes it as easy, or easier, than Word given that Word changes it UI layout every few years

Well your post here has non-ascii characters. But perhaps you wrote it in in Word and copy-pasted it into Internet Explorer. I've seen that approach recommended to avoid data loss. It's not entirely clear what your objection is tho, since you recommend permitting UTF-8 which allows you to represent many many more non-ascii characters than ascii characters.

Are there any startups building legal tools with nice UX, but git as a back end?

We considered it. We even built some prototypes and showed it to various stakeholders. The response we got back was universal - "We want everything to feel like we are in MS Word."

This is so true! Developers often don’t realize how much MS Word can do and what its users think about the rest of the world.

B.t.w since it’s about the US Constitution it is customary for me to share a link to its book form on the web:

https://bubblin.io/cover/the-united-states-constitution-by-u...

Legal professionals don’t want version control because they don’t want their mistakes to be visible to anyone else.

Google Docs would actually be a good fit for this. You can suggest edits, comment, see a version history, ...

In Word, too. Without selling your soul the devil: Microsoft merely demands a fee for the product.

cognitive load

They same applies to software professionals who just would like "to code". Yet, the leverage of distributed version control proves to be exponential in the end.

It really doesn't.

In software, you need to track versions because you keep everything in multiple files, and you're making changes to multiple files, and you can have regressions with each new version.

In a negotiated legal document, you have just the one authoritative version: the offer you've sent to the other party (or the counter-offer they've sent back to you). For lawyers, this takes the form of edits to the document as highlighted by the Track Changes feature. (Prior versions are basically irrelevant except for historical interest.) And even then, the document going back and forth isn't even the executed (aka "production") document, it's just the development version. Once the document is executed, the development versions get deleted because the executed document is the only truth legally and so prior versions absolutely do not matter.

One can equally think of the entire code base as a single document, and of the release version as an executed document. In the long run the non-release repository states don't matter that much either, they're just helpful for anyone willing to gain an insight on why the things work the way they do.

One can equally think of the entire code base as a single document

No, you literally can't. They're separate files. A legal agreement is just one document. It makes a world of difference for version tracking.

Also, software has versions. If you have an issue, you can just rollback to a working version. Legal agreements don't have multiple working versions. They just have the one, and you don't get to update it, because if you change it, you have a different agreement that supersedes all old copies, which are now longer worth the paper they're printed or or the bytes that store them.

Sure, you could have needlessly more complicated version tracking for legal documents. But Track Changes in Word works fine, because the legal field doesn't need anything more complicated.

I literally can think of the entire code base as a single document. It happens to be multiple records in a database, but that's not intrinsic to it.

In the same way, i can literally think of my legal documents as a single document (say, a visa application) with multiple files (say, a petition, a copy of my wedding certificate and a reference from a friend). [Ironically, this language is precisely the reverse of what you would say with the printed copies.]

When they're printed out you can't tell what the boundaries are. Don't get confused by the implementation and the abstract concepts. If there's a distinction that doesn't work well, you can change it. Maybe version 2035 of Word stores every paragraph in a separate file inside a zip archive. There's no reason Generic Version Control System 2038 couldn't be written to peak inside those archives.

A legal agreement is one document, sure. But a large scale legal operation like a sale of a company must consist of thousands of documents that are changing in concert, right? Wouldn't that be a case for a more comprehensive and consistent change control process?

No, the sale of a company is governed by the one sale agreement.

manifest as one singular physical "file" with nothing incorporated by reference? Interesting.

That is correct. Nothing can be incorporated by reference. The closest you can get are attachments which must be incorporated by the time the document is executed.

This. Other versions of a proposed contract floating around a deal do more harm than good.

Ideally, settled issues should remain settled as remaining outstanding issues are resolved during the deal-making process.

But, this is a western tradition/convention, Asian deal-makers seem to be more than happy to look back and re-open settled issues, driving American lawyers insane.

If the legal field doesn’t need anything more complicated, I suppose you think this Git repo is a pointless novelty, not something that would actually be really useful if it were available and authoritative for all statutes?

We're talking about two very different things: a single legal agreement vs a database of laws.

Something like this already exists in multiple forms because it is very useful. It's so useful that the owners of those sites can charge lawyers a lot of money for access... Hundreds of $ per month.

They wouldn’t be able to charge so much if the laws were published using a machine-readable version control system. Citizens should expect this from their legislature; lawyers shouldn’t be allowed to paywall historical information about public laws. This Git repo is a good illustration of how easily the legislature could solve an important legal problem with free software engineering tools that facilitate reuse and permissionless innovation, rather than leaving companies to solve it with crappy paywalled web apps that contractually prohibit reuse of their content.

> In the long run the non-release repository states don't matter that much either

That's not true. Many a times I needed to comb through old commits for debugging purposes.

Also, with multi-branch development, you often have many non-release branches that are relevant at a specific point in time.

Reply on news.ycombinator.com