Ask HN: Why hasn't Git been adopted outside of software engineering?
Yet even highly technical fields like scientific publishing, that already use LaTeX for which Git would be a perfect match and could dramatically improve collaboration, still mostly default to sending versions of documents back and forth by email.
I don't buy the explanation that Git is somehow too complex. First, there are all kinds of GUI frontends that hide away the intricacies of the commit flow. Second, it's not like other fields don't already use extremely complex technical tools every day. Git is trivial to use compared to some of the software prevalent in process management and accounting, not to mention civil engineering disciplines. Even Excel is much more complex than Git.
So why is Git still being ignored pretty much everywhere outside of software engineering?
Or perhaps the better question is: Why does software engineering consider Git indispensable, when every other field, including science and civil engineering, seems to get away without it or any equivalent tool?
57 comments
[ 3.4 ms ] story [ 123 ms ] threadIn car parts the last letter is the revision.
Electronic boards have revision numbers: https://youtu.be/LBoF1e5YDdQ?t=799
I can only recall a company that used Perforce's image diff.
And a book author, Stoyan Stefanov, suggesting Git for book edits. https://blog.stoyanstefanov.com/dear-technical-copyeditors/
A report doesn't have ten people writing the same page. If everyone writes a chapter then merging is trivial. No need to learn a complex tool
IMHO, git is fine for software, and that's it.
Git is decent tool for code. But for many other problems there could be much better tools developed. That could include such things as reviews and comments and different organisation of information, also consistent linking to specific sections in other parts of storage. And by reviews and comments I mean something permanent that is also stored in version control. Not something ephemeral like average code review tool.
I haven't tried Legit, so I can't comment on it, but I do think that new git interface ideas are certainly doable. They just need to pass a certain "painless" experience that tools like Perforce provide. If a game artist using only Maya/Houndini can check in their files without worrying about the underlying decentralized tech, IT departments would switch over in a second.
Marketers and documentation writers use markdown and git for building websites and books.
Data scientists use git for their notebooks.
Operations use git for their deployment scripts.
Git isn't the best for office documents. Revision marking (aka, change tracking), document comparisons, and merging are all available in Office suites. Git isn't really used here because there features predate Git, operated on binary files or complex XML documents (neither of which are conducive to diffs).
Git isn't good for databases or data lakes. The files are huge and typically aren't modified (CSV) or are binary/compressed (Parquet).
In the software industry, sure. Outside of it, I'm willing to bet that 95% of marketers have no idea what Git is.
And Markdown? This again seems highly specific to the tech/open source/blogging microcosm. In the "real world" it's all Microsoft Word, or DTP tools for people who are closer to the printing process.
How many of these use git correctly?
https://github.com/DCCouncil/law-xml
Similarly, the entire German Federal law can be found on Github:
https://github.com/bundestag/gesetze
It's not that lawmakers or their staff are actually using Git when drafting laws and other legal documents. More like "look, we've arrived in the 21st century, because we allowed one of our summer interns to create this repo in our name".
The Bundestag one is an outreach initiative, making it easier to track law changes.
Perhaps you meant "official" rather than "authoritative"? As in "published by an actual lawmaking institution", but not "the authoritative reference for those laws".
You bet I do. Look at any state or municipality that's adopted fire and electric codes from their respective trade groups. Or look at the relative power of companies like Westlaw.
https://www.latimes.com/business/story/2021-03-18/state-laws...
I don’t know how true this is, or how you have concluded this. It feels like people you know don’t use git for this purpose. On the other hand, everybody I know uses git with LaTeX. Where does the border go? It might be dependent on the discipline. Biologists might not even know the existence of git.
I've worked in civil engineering and we definitely used 'equivalent' tools, primarily Projectwise and Perforce. The main problem is that git's support for large files and binary data is pretty bad, and no one over at "git HQ" seems particularly interested in solving the problems this market has. All the Git UI tools that exist are written by and for software developers, with no thought as to what the actual needs of managing a large Civil engineering project actually are. Git offers no value, compared to other tools, if 90+% of what you are checking in are things like CAD files, Excel sheets, elevation models, and geotechnical survey data.
I don't doubt that it's possible to build a tool useful for civil engineers (and other fields with similar challenges) on top of git, but as far as I know no one has showed any interest in that.
Even if they are very common, I think there are many, many people who rarely or even never write a text file. If you ‘live’ in a combination of Outlook, Word, Excel, Slack, a few web sites (company wiki, Facebook, etc), maybe a company database, where are those ‘very common’ text files?
Also, how do you store your Slack or Teams discussion in git, together with your emails, word docs, etc?
There also is the issue of legislation that requires people to throw away data. Yes, you can rewrite git history to delete the files associated with J. Doe’s application for a given job, but git doesn’t make that easy.
Git a is distributed version control system that most people shouldn't have to deal with. It has awful tools and doesn't work well with binary files, large files and moved files. Just an example: How do you diff two copies of an excel document with Git?
Most people don't have to deal with multiple "master" branches with no single source of truth because that's really what Git is for.
What most people need, including software engineers working in closed source, is a single source of truth with good history, diff and large files support.
I believe a tool like Dropbox or even centralized version control systems like Subversion or Perforce are better positioned to solve this than Git.
Many cloud based tools already have features that give them the upper hand over git. For example, Google docs allows collaborative editing and editors have access to file history and can revert to specific versions.
Maybe there are tools to diff binary files like two versions of an audio file or two excel documents or whatever two [domain specific file format] documents.
I will be happy if version control came at the file system or cloud drive level and the app just leveraged this integration seamlessly instead of forcing everyone to learn the difference between between branching, rebasing, cloning, copying, stashing, etc...
Honestly, what does git buy you compared to saving files with version suffixes?
1. cherrypicking - is that really that useful outside of programming?
2. branching - can be done without git using folders
3. merging - can be done without git using beyond compare
4. distributed fs - can be done with dropbox
5. cleaner than having millions of files around
On the other hand you would need:
1. to go from your comfy folder/file mindset to the difficult commit tree concept
2. to learn git commands - yes it is a pain in the ass, even for seasoned developers. Especially when in conflict land, git is foot shotgun.
3. to setup a git repo somewhere - also pretty difficult for non developers
4. to learn some ui cause yes, the cli is too painful to use
I don't buy it. Sure, Excel is a monster (in size and features) compared to Git, but the average user only has to do 2 things to start using Excel: 1) open Excel (or an Excel file), 2) click on a cell. Profit
Whereas with Git one needs to know what a branch is, what a commit is, what push means, to have a remote repo, potential conflicts,... For computer geeks like us, this is no problem, but for people who don't care (don't need to care), Git is all but "straightforward".
On two occasions (different people) in the past year, I got in a very confusing conversation with someone asking for help with git, because they kept talking about how they did a "pull request" when they really meant they did a "git pull".
The problem is that it does only really work well for plain text. So office documents don't work, emails only kinda work (html; and anyways already handled by other apps) and for binary files it provides no real benefit.
> could dramatically improve collaboration, still mostly default to sending versions of documents back and forth by email.
What is the supposed benefit of git for this purpose over dropbox/owncloud/seafile...? For plain text the version history/branching etc are all useful. For binary files or office documents, git just seems much more work for no gain.
Excel is binary, because its compressed XML. Not a good fit for Git.
Yes it is complex, for non software engineers.
Other professions use different version control systems more adpated to their needs (for instance large files...).
One interesting anecdote / micro case-study: In my family we have a vacation home that we rent out. My mom (>70 years old, completely non-technical) manages the renting and updates an online calender where guests can see which dates are available at what price. I developed a very simple custom text format and a static site generator an my mom changes the data using the web-ui of my gitlab instance. I had to teach her but now she is very happy with it and much faster than with the previous solutions. And git helps greatly because mistakes do happen and its very easy to revert and see when they happened etc..
Same goes for Excel, Word, etc.