Ask HN: Why hasn't Git been adopted outside of software engineering?

Maybe the better question to ask is "why isn't file reversion control adopted more outside of software engineer?"

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...

Binary diffs are not useful, unless the diff software understands the underlying format. Most formats are linear but many are not, and many formats permit different binary encodings of equivalent data. Imagine for example archives created from same directory tree but by different implementations. There's no reason to develop this feature in git, because that's a lot of maintenance for little to no use. I don't see why spreadsheets should be any different. If they contain plain text that should be diffable you can remove non printable characters and pipe it to diff.

when every other field, including science and civil engineering, seems to get away without it or any equivalent tool?

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.

Git LFS?

Feels like a hack and a workaround rather than an integrated part of git. From a UX perspective it's a hassle to deal with and inconsistent (different files require different commands to manage based on...if they're "large"?) and it seems to be rather unloved and ignored by most git UI tools and git developers.

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 Excel is much more complex than Git.

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".

Agreed. For many people forced to deal with git, the git concepts are just word salad.

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 District of Columbia uses Git to track law changes as well.

https://github.com/DCCouncil/law-xml

Similarly, the entire German Federal law can be found on Github:

https://github.com/bundestag/gesetze

To my knowledge, those are outreach initiatives by the respective institutions with the goal of appearing more "tech savvy".

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 District of Columbia law git repo is the authoritative source as far as I know, so not really an outreach initiative. I do not know whether the lawmakers actually actively use it, or that they, more likely, just let clerks do it for them.

The Bundestag one is an outreach initiative, making it easier to track law changes.

Authoritative source? No way. The authoritative source are the legal gazettes and official publications, just like they've always been. You think the legal profession will accept an XML repository, hosted by a private company serving the software industry, as authoritative? That's absurd.

Perhaps you meant "official" rather than "authoritative"? As in "published by an actual lawmaking institution", but not "the authoritative reference for those laws".

> You think the legal profession will accept an XML repository, hosted by a private company serving the software industry, as authoritative? That's absurd.

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...

> Git works with text-based file formats, which are very common outside of software engineering

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.

Plain-text files are actually not widely used outside of software engineering and when they are, they are used like binary and only edited with graphical editors. And most non-tech people don't see the benefit if it is there - in software development versioning was born from pain: big source trees are unmanageable withoud SCM. For typical office documents you miss some benefits but can live without.

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..

Wow, this is very interesting anecdote and case study for Git based user application. This can be an excellent Local-First kind of software that can work for and appreciated by the non-technical people. Are you opening up the custom software or is there any equivalent of available software that can perform similar to this scenario?

I don't have real plans to open this up as it is very specific for our use-case - perhaps I might clean it up a bit when I have time and put it on github. I don't know of any equivalent software.

It's interesting that you describe your use case as "very specific" now, but earlier it sounded like a thing that that thousands of other people might do similarly. What makes you not want to do things their way; what makes them not want to do things your way? It sounds kind of like Airbnb/Vrbo but without the expense and protection of a well-paid middleman, in which case I'd expect lots of people to be interested.

conceptually many people might want to do it the same way. But the apartments and pricing model (different seasons) etc. is hardcoded.

Git IS heavily used outside of software engineering.

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).

> Marketers and documentation writers use markdown and git for building websites and books.

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.

It seems like broader adoption of Markdown (or similar lightweight markup) would greatly help with broader adoption of git.

> Git IS heavily used outside of software engineering.

How many of these use git correctly?

How many people in software engineering are using git 'correctly', and what is 'correctly' for that matter? At the last place I worked different projects in different offices had all developed their own git workflows and none of us could agree on who was "Doing it Wrong".

Briefly - because the cons outweigh the pros.

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

Oh and in programming we can't really do versioning by changing filenames and folders, cause that would break the build tools. But a lot of people building static websites use folders for versioning.

Because git UI sucks. I've been using git for 10 years at least tried mastering it 3 times, even now I'm exactly 30% sure what is happening if I'm using a not top 4 command

But as I mentioned, there are many tools that wrap Git's low-level command line interface, some of which build entirely new UI paradigms on top of it (e.g. Legit).

All those tools are great until something happens that they weren't designed for, and then you're back in the command line but without any experience of the easy stuff.

I've been on software teams where there were varying levels of git experience (mostly experienced programmers that grew up on Perforce) and I found that new programmers would often get blocked when the repository underneath the UI got into a particular error state (especially when rebasing or merging). Someone who knew git a little better would often have to help get them "unstuck" so they could continue doing their task. In my industry, there's certainly a camp that would prefer we only use Perforce as its a more practical and seamless tool for them.

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.

Because as a community we are highly masochistic and source perverted pleasure from teasing others especially during interviews. Another industry with desperate need for version control is law, instead they use the most hopeless solutions like Word documents and email conversations. Ask any lawyer what version control are they using - they will charge you EUR 100 for the answer and the answer will be "none".

I agree law could certainly use good version control designed for it. But advertising git to be it seems more likely having hammer and every problem being nail.

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.

It doesn't seem that user-friendly or easy to get into. But maybe it's just an outsider perspective.

> There's essentially nothing about Git's functionality that is specific to code. Git works with text-based file formats, which are very common outside of software engineering, and supports binary files as well.

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.

> 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 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 think it might be due to the compunding factor of multiple people working on multiple files concurrently. Collaboration in research is more limited to sharing information, and when writing does take place at the same time it is only usually a couple people working on it. The frequency of sharing files could also be a factor. Also I don't think anyone wants to learn to use another piece of software among the dozen they already have to use. Emailing a latex file at the end of the day seems much simpler.

Nobody has mentioned pull requests, content review, managing commit/write privileges. There's a bunch of basic workflow things there that version control systems can facilitate. That doesn't mean you specifically need Git (or even a general VCS) for those things, but there are places where it could beat the status quo significantly.

I would say that there is not enough use cases that show and say "Look at us - we are using Git". I recently switched from WordPress to GitHub pages. It has all that I need. But then again, I work in IT. I'm not sure who from my friends would trade Wix or WP for Git.

Same goes for Excel, Word, etc.

SharePoint has versioning. Also, in industry you see on the footer of forms their revision/version number.

In car parts the last letter is the revision.

Electronic boards have revision numbers: https://youtu.be/LBoF1e5YDdQ?t=799

Sure, but all of that is primitive by the standards of version control systems used in software engineering. An incrementing number to designate a specific revision is not comparable to having branches, merge strategies, cherry-picking, bisecting etc.

can you think of a scenario where you need something like that.

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/

The same scenario that software engineers use it for: Combining work from multiple collaborators into a coherent whole. I don't see why this would be less useful for e.g. a policy institute collaboratively writing a report than it is for programmers collaboratively developing an application.

How often would this kind of report writing, which may involve many reporters, happen in an org like that? I don't think someone would like to invest in training and tooling for something that might happen once a year.

All the time? Such institutes push out 300+ page reports on a regular basis. Do you think those are written by a single person?

While that is true, one could argue that these reports are either split into distinct parts written by individual authors or are not written in parallel.

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

For drafting yes, but at some point someone will probably want to edit or review the parts collectively. It's easy to prematurely consolidate the chapters into one file, and then any further changes have to be merged into the 'master'. A proper VCS can help here.

But do you need that? How useful is cherry-picking in manufacturing (I guess not so much)? Why should one change a perfectly working system with something new - as far as I know, revision numbers in manufacturing are perfectly fine.

IMHO, git is fine for software, and that's it.

Many software projects have their documentation in Git. That is partly to have the documentation sitting alongside the code, but I would argue it's also because Git is good for managing documentation. Other fields have similar types of documentation and content that Git could be be similarly useful for (whether it's worth learning Git just for those purposes is another question).

If there is a business/domain need for this capability most organizations will go with some kind on content management solution (CMS) of which there are myriad solutions. Git would be considered bare bones and unintuitive compared with the best of these tools.

Over the years, I've seen entire books being written on Github, with all the grammar and spelling mistakes, warts and all to be seen in the diff. This is true of documentation & blogposts on Github too. Github is not just about software.

> I don't buy the explanation that Git is somehow too complex.

Yes it is complex, for non software engineers.

Other professions use different version control systems more adpated to their needs (for instance large files...).

Git is too complex for many software engineers as well. It has a lovely engine crusted over by a terrible UI.

But people do use version control. On Windows you have access to Shadow Copies and on Mac you have Timemachine.

Excel is binary, because its compressed XML. Not a good fit for Git.

But git (and more generally diff) is not very efficient for detecting and showing moved text (which it displays as deletion+addition)

Good point, but then the question is why haven't more suitable diff tools been developed?

git is commonly used with Latex. Popular online editors like Overleaf have GitHub integration for example. But most Latex users are probably rather close to technical domains like programming.

I suspect the existence of Google Docs is the main reason.

Not one mention of Fossil source control.