Ask HN: “Git” for Microsoft Office?
I’ve recently changed job and now I am basically swamped in MSOffice documents. This makes collaboration very hard: people are fearful you’ll touch their precious files, there are manual procedures to produce “gold” documents, fixing a typo is an ordeal, and if the same slide is present in 15 Powerpoint decks any edit will require tons of mindless and error-prone copypasting... it made me realize how good developers have it with git, github, and the likes.
Is there anything out there, capable of working with MSOffice stuff in a granular and collaborative way? I can’t believe non-geeks have lived like this for 30 years.
148 comments
[ 3.3 ms ] story [ 215 ms ] threadYou can have that Golden Version and everyone can suggest changes and edits, then the document owner can accept or decline the edits.
[1]: https://support.office.com/en-us/article/Collaborate-on-Word...
>if the same slide is present in 15 Powerpoint decks any edit will require tons of mindless and error-prone copypasting
This is exactly what you want SharePoint for. Have 15 people open the same PowerPoint deck, in desktop PowerPoint, editing the file simultaneously. It's fully versioned and you have no merging of files back together.
I wish there was a “pull request” for office with a permission that allowed suggestions but not edits.
Intuitively, this doesn't really seem possible to me for a sophisticated document format. E.g., how would you represent a change to an embedded graph in a pull request? (And would that same approach scale to any form of embedded media?)
A procedure is made up of many flows that are linked together. Everyone that uses the procedure views the "live" flows (like a master branch). Each user gets their own branch which we call a "draft". In a draft, a user is free to make any changes they want (add/delete/modify flows) and then submit all the changes for approval. Approving the change request then merges the changes into the "live" for everyone else to see/use. I even went so far as to build side-by-side diff of the flowcharts, rebasing/merging with live, and conflict resolution.
It's simplified in the UI so the terminology isn't 100% like git. But, one of our biggest hurdles though is actually teaching users how this works why it's better than the current mode of document locks/real time editing. And when our customers "get it", they really fall in love with the concepts and why it's better!
[0]: https://procedureflow.com/
My current understanding is that live collaborative editing is the solution for the same problem version control solves for non-plain text file formats (and therefore, also the solution for non-programmers). Think of how much programmers complain about the complexity of git, and that's using it with plain text, a format that facilitates version control like no other.
For collaborating in every document format that isn't plain text, my solution has been to use live collaborative editing.
I recently worked on a word doc with four other collaborators. Someone inserted a footnote. Looking through versions it took me 10 minutes of sifting through the dozens of versions (auto save creates new versions very frequently) to find who and when that section changes.
I wish there was a git blame for office.
I also wish the old day of “checked in” versions where I could set a number and a comment.
That's exactly what "Track changes" is for.
Blame goes through the entire history of a file.
I’ve looked into what it would take to make a git style system for docx (since it’s just zipped XML, right :D), and the file format was a nightmare whenever an edit was made. Someone smart should take a look at it, as there would be a massive market for a DVCS for Office files. Imagine a world where every bill in Congress was committed to a central repo so the whole world could see the changes, or where someone in your team wants to play with the formatting on a shared requirements document without breaking the page you’re writing on. It would be a boon for productivity.
Meanwhile, people who have no such expectations cope perfectly well.
You know how they do that right, stay in online chats and ask who, how, why, when. Awful waste of efforts
On Office 365 at least, it does tell you all of those things.
For example, the Federal Data Strategy, https://strategy.data.gov/overview/, is created from https://github.com/GSA/data-strategy
It’s been nice to follow updates and the specific changes using git diffs.
You also dont need to use OneDrive to sync SharePoint, you can use the File > Open menu to open in Word, Excel, PowerPoint to open files directly.
Would there, though? I mean, we HN readers want that, but I don't see any evidence that the average Office user is clamoring for it. Even comparatively crude systems like Track Changes aren't used in my experience as often as they could be, and those are a hundred times easier for non-technical people to wrap their minds around than a Git-like system would be.
I suspect that part of the reason this problem is so intractable is that it's really two problems. The first is actually tracking the changes to the underlying document, which, as you note, is hard enough by itself. But then on top of that is the second problem, which is that you'd also have to come up with an interface that could make the power of a Git-like system comprehensible to non-technical users. And you'd need to solve both problems to have a product that would actually be ready to take to market.
My current experience is that non-geeks have no idea that another way of life is even possible. You won't clamor for something you cannot even conceive.
I bet that tons of orgs would rush to adopt a github-style workflow if MS made it available. After trying out the "Track changes" and collaborative modes people have mentioned here, I can see why people in my company don't use them - they are flaky and don't really enforce rights, they basically just nudge the user.
Copied from another one of my comments in this thread:
A procedure is made up of many flows that are linked together. Everyone that uses the procedure views the "live" flows (like a master branch). Each user gets their own branch which we call a "draft". In a draft, a user is free to make any changes they want (add/delete/modify flows) and then submit all the changes for approval. Approving the change request then merges the changes into the "live" for everyone else to see/use. I even went so far as to build side-by-side diff of the flowcharts, rebasing/merging with live, and conflict resolution.
It's simplified in the UI so the terminology isn't 100% like git. But, one of our biggest hurdles though is actually teaching users how this works why it's better than the current mode of document locks/real time editing. And when our customers "get it", they really fall in love with the concepts and why it's better!
[0]: https://procedureflow.com/
Technically, you could use git, and it works decently with the xml-based Office file types, but it's a hard job to get people used to the workflow, and things like merge conflicts are going to be even more of a headache.
I beg to differ as normal people would expect their old documents to work, and the subset of things that work in web is not enough. Quite like LO-supported, totally not on par with native.
Is track changes not good enough?
(2) What happens when someone checks in a hand-reconciled merge that is not a valid XML file, because whoops?
Second point, I haven't tested this, but docx, xlsx etc are XML based and may be happily Git compatible.
Third point, if the above doesn't work, look into automatically saving / converting documents into and out of a Git compatible format with minimal loss of formatting etc. You may be able to convince your team that this is an acceptable compromise between the tools they are used to, and the power of DVCS.
Which make a version control pretty much impossible.
Indeed, pass (https://www.passwordstore.org/) uses this to allow diffing and sane tracking of its password files, even though they are binary encrypted GPG blobs.
I do this with LibreOffice. I've not tested Microsoft Office with this workflow.
A couple years back I built this: https://github.com/tomashubelbauer/modern-office-git-diff
It is a pre-commit script which unpacks Office XML into text contents and tracks that alongside the source file. This way you can consider the binary to be a source of truth, but with each commit you also get a textual diff showing what changed content-wise. More or less.
Some person built the same thing for OpenOffice and I link their project in my readme, too.
Thanks!
You can do that with pandoc[1] as a git diff-viewer[2] too.
[1] https://pandoc.org/
[2] https://github.com/vigente/gerardus/wiki/Integrate-git-diffs...
Given how shitty MS software has always been, I can't believe people not only pay money for it but also accept it as the norm.
As for your question, non-geeks have been coping with this by saving a copy of a document before each edit so that when the inevitable catastrophe occurs, they can roll back. As a geek, you can use git manually. Adding that as a feature to Office would make it even more incompatible with itself than it already is.
* Document1 FINAL
* Document1 FINAL DRAFT (DO NOT EDIT)
* Document1 FINAL EDITED
* Document1 v2 FINAL
- Substantial changes result in a new version number at the end of the file:
Document v34
- Branching to try out ideas uses a marker what this idea was:
Document v34-2 test-color-scheme
If the idea is approved, it results in a new version:
Document v35
- Tagging for long running designs adds the context where it was last used, this can be considered a final release version
Document v36 - July 2020 promo
Once a file is used like that, an export copy with the same name is saved in the same folder:
Document v36 - July 2020 promo.pdf
This document is copied using a general name and then moved to a different folder:
promo2020/july/flyer/Document.pdf
This is what is printed, e-mailed etc. Date and file size allow comparisons to find out which version this was.
While this falls apart for testing a lot of similar ideas at the same time, it has served me well to have a history of snapshots and their context, have all final documents archived, and ignore (or delete) all the versions in between, while still saving progress over days/weeks.
https://www.theverge.com/2020/5/19/21260005/microsoft-office...
https://support.microsoft.com/en-us/office/get-started-with-...
I'd be happier with something that simply allows me to have a github-like workflow where I can propose and justify changes to this or that block of document, and an owner can sanction and merge. This would not touch internal hierarchies (the most sacred element of corporate life) but would improve collaboration.
If Fluid is a step in that direction, it's welcome. Unfortunately to me it looks more like "web-native COM objects" and few people ever liked those.
This is called 'Tracked Changes' and 'Comments' in Word. Under the Review ribbon.
Here's the How-To: https://support.office.com/en-gb/article/track-changes-in-wo...
Absolutely not comparable to a github experience, as far as I can see.
This is what I did in college because (for some reason) everyone expects word files for everything.
Less than a year later I left that job. I'd rather learn a trade than be paid to use MS Office.
Part of my company uses SAP for their doc control, part of my company uses MasterControl. I hate hate hate SAP. I have a few bones to pick with Master Control, but overall, it's tolerable. If you'd like to chat more about how this process works in the workplace, you can find me on twitter @failbridge or on reddit as /u/daveslash
Is not perfect but it works.
Tested with TortoiseSVN 1.11.1, TortoiseGIT 2.10.0.2, MS Office 2010 on docx documents.
It’s very hard though, because the files combine data and styling. Plus, the data is spread over several XML files.
If you want to message me: jan at the domain above
Edit: While Google Docs, Office365 and other collaborative editors are great for editing a document at the same time, from my point of view the real power of Git is branching, merging, and having a concept of distinct versions (which may consist of several files).