Live data from Hacker News

Using Microsoft Word with Git

blog.martinfenner.org

41–50 of 136 posts

Re: Using Microsoft Word with Git

#41

Earlier quoted context omitted.

> If you're collaborating on a document then markdown or LaTeX has you covered. These are not WYSIWYG solutions which answers 99% of your question "why". When people want to write a document they want to write things and have the things appear on a page, possibly in different formatting. Injecting ideas like source files, rendering pipeline, etc. will just result in confused people. That's why online solutions like G…

I think my argument is that WYSIWYG needs to die. For the vast majority of people they want nothing more than: > text > image > more text > table > more text There are any number of applications that allow you to write markdown and view the generated HTML in whatever formatting you want. Your recipient then gets to choose their own fonts, colours etc, which from an accessibility point of view, is much better. Unless…

I don't believe you'd be able to convince anyone not in tech that writing "![](path/to/file.jpg)" is in any way better than clicking "insert image" if you just want to send someone a report. Never mind explaining that paths need to be relative and resources included in the attachments.

Even I, happily maintaining some pages in reST, wouldn't want to inflict that on people.

Re: Using Microsoft Word with Git

#42
Before Word integrated its own improved version tracking in more modern versions, during my undergrad I participated in a research project to add version tracking to Word documents by abusing its zip file format[1]. My research partner created a plugin to manage the versions, and my main contribution was a Java tool that attempted version merging[2].

It wasn't fleshed out or usable, but it was an interesting project. I was impressed at how open the Word/Office format was, this was before Microsoft's reemergence into openness and open source.

[1]: https://dl.acm.org/doi/10.1145/2723147.2723152

[2]: https://github.com/jacobmischka/Vvord

Re: Using Microsoft Word with Git

#44
post #19

FWIW, if you're using libreoffice write you can save your file as a flat odt file (.fodt), which gives you a version-controllable format

Interesting, I didn't know about fodt! Only knew that godot engine had done something similar (for git specifically). I downloaded a docx document from the net, opened it in libre office, removed a single word, saved it as fodt, removed a single word again, saved it as fodt again, and the diff between the two fodt is gigantic. Apparently there are lots of items like whose content didnt change, but their ID did. It di…

You were probably the first person to try this workflow in years.

Re: Using Microsoft Word with Git

#45
post #39
post #22

I don’t understand why this 6 year old article has been posted when current Microsoft 365 versions of Word et al have built in version control and real time collaboration.

Yep. They've had version control for at least a decade, diff'ing also, by way of Compare. I'm also not sure why people are fascinated with using git here. It's weird seeing all of the complex solutions in this thread for a problem which does not exist. Edit: I meant 'fascinated with using git here in this context'.

i don't know why you are getting down voted for speaking the truth. I don't know a single person who this article would relate to in today's climate since everyone i know is using the latest version of office or on google docs.

Re: Using Microsoft Word with Git

#46
post #6

Not long ago I read some article here on HN that the world is still waiting for a git equivalent for documents. This seems like a good start. Now we need a native diff viewer for structured files, where the changes are presented with attribution either side by side, or alongside (like gitk, or like gitlab diff viewer). Then we need an editor that supports doing the gitty stuff natively, so that the non-technical writ…

Tip: Zoho Writer - https://writer.zoho.com is a Google Docs alternative and comes with additional tools to compare docx files.

https://www.zoho.com/writer/help/document-tools.html#Combine...

Re: Using Microsoft Word with Git

#48

Earlier quoted context omitted.

> If you're collaborating on a document then markdown or LaTeX has you covered. These are not WYSIWYG solutions which answers 99% of your question "why". When people want to write a document they want to write things and have the things appear on a page, possibly in different formatting. Injecting ideas like source files, rendering pipeline, etc. will just result in confused people. That's why online solutions like G…

I think my argument is that WYSIWYG needs to die. For the vast majority of people they want nothing more than: > text > image > more text > table > more text There are any number of applications that allow you to write markdown and view the generated HTML in whatever formatting you want. Your recipient then gets to choose their own fonts, colours etc, which from an accessibility point of view, is much better. Unless…

You're speaking absolute crazy talk man.

>Write markdown

You have now lost almost all people who currently write documents. Nobody who is not a developer wants to write in markdown. The mass market wants point and click, buttons, and WYSIWYG.

Re: Using Microsoft Word with Git

#49
I'm using Fossil for my book. My book is about business systems simplicity so it's a great fit. If I hadn't started using sqlite for a project, I would have never even heard of Fossil. What a great, beautifully simple combination. Don't add complexity unless the complexity is worth the dysfunction it addresses.

Re: Using Microsoft Word with Git

#50
post #17

My SaaS deals primarily with legal documents that for years had been maintained with Word. The pain of emailing documents is real, but the comfort level with how Word works is also real. Over the years, most organizations have developed internal workflows to share and send documents around that bypass the pains, and while they may not be perfect, they work. The funny thing is that the document authors like these ways…

Having a lot of experience in both legal (academic and lawyer) and tech (developer and founder), I totally agree with you and think you framed very well the situation. As a lawyer I can full confirm that our industry works as you have described (as regards documents workflows), and with my tech background I can also confirm that most features of dev-oriented solutions like git are mostly uninteresting from a lawyer's…

Similarly, I am a qualified lawyer. I previously worked in a big law firm in London, which describes itself internally as both the “best” and “the most advanced” law firm in the world. I now work full-time as an engineer in software, and increasingly in hardware.

I agree with both comments.

To add, in large-scale corporate/commercial practice (which is the area which I practised), Git would be useful in replacing email-based collaboration, but the switching costs seem too high.

Currently, the corporate law contract negotiation workflow is as follows:

1. a party adds their tracked changes to a Word document based on a template contract;

2. the party emails this document to party B;

3. party B reads the changes, may discuss the changes with their client, adds their tracked changes, and then emails the updated document to party A.

This process repeats for every document, punctuated by occasional conference calls between the parties, until the parties agree.

‘Git for law’ would be useful for lawyers in increasing efficiency - and thus reducing costs for clients.

However, the benefits for law firms of adopting a new Git-based workflow are likely to seem relatively small to lawyers. Their current email-based version control system is messy and time-inefficient, but generally functions with minimal error.

On this basis, I would predict that most corporate law firms would be very slow to adopt a Git-based system - the benefits may not justify the costs.

One should also note that lawyers, particularly contract/commercial lawyers, are conservative by profession. In my experience, most lawyers are very slow to adopt new technologies, highly risk-averse, and skilled at spotting risks. The combination of these traits means that any technology will have to offer a very high benefit to replace an existing legal workflow.

Post reply on HN