Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Microsoft Word with Git

blog.martinfenner.org

Post reply on HN
Print view View original

61–70 of 136 posts

Re: Using Microsoft Word with Git

#61

Post by CJefferson »

MarcScott wrote: post #28

I really don't understand how Word remains so popular. It was created at a time when few people had internet access, and was designed to produce printed documents. It was the perfect tool to write newsletters, flyers, articles, academic papers and manuscripts. The world has moved on though, and I fail to see Word's relevance today, other than the sheer number of people that are familiar with it. Word is expensive, pr…

I agree that word is bad, but I don't think we have a great replacement yet.

Markdown -- standard markdown isn't expressive enough (no tables for example), there are lots of extensions but none which are "standard".

LaTeX -- doesn't produce accessible documents, so is a non-starter in lots of areas (seriously, the PDFs it generates are some of the worst around when it comes to accessibility. Word's are amazing).

Re: Using Microsoft Word with Git

#62

Post by acbart »

PaulHoule wrote: post #58

You do know that a Word document is really a ZIP file? The text content is inside an XML document that, in principle, Github would work on. All you have to do is unzip the document, store the directory in GitHub and repack it for Word to use.

Wait, wouldn't this actually be fairly simple to set up? I'll admit my Git knowledge is a little shaky, but couldn't you set up a Hook that runs when you commit a Docx/Pptx/etc. file to unzip it in memory first, and then another Hook when you checkout to zip it back into the original structure? I guess conflicts are the major issue... asking users to navigate the XML/binary structure stored inside could be a mess. A GUI could help, but that would invoke different issues.

ETA: Apparently right below this comment someone has already created this: https://news.ycombinator.com/item?id=24303611

Re: Using Microsoft Word with Git

#63

Post by coliveira »

codingdave wrote: post #14

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…

The big problem with git for word is that git is not designed for the population in general. Using git is not easy, even for developers. Although powerful and flexible, it has a very complicated workflow that is too close to its implementation. In my opinion it is just like wishing that the general population use LaTeX instead of Word.

Re: Using Microsoft Word with Git

#64

Post by bovermyer »

ectoplasmaboiii wrote: post #15
bovermyer wrote: post #11

I gave up using Word to write manuscripts when I switched to Markdown documents in git. In the last few months, though, I gave up on Markdown to switch to a more robust format - LaTeX. Before I switched, I didn't know LaTeX at all, but I knew from my reading that it had the features I needed.

I don't know if you're already familiar, but pandoc perfectly bridges this gap for me. You can write things in markdown, then covert it latex no problem with pandoc. You can even make templates for it, and write mathmode in markdown. It certainly makes for less _noisy_ source files in my opinion, and it also means that you get to take advantage of the fact that, if you want to, you can easily convert your markdown to…

I was converting Markdown to PDF with pandoc before I started writing straight LaTeX.

It's worth noting here that I'm writing layout in LaTeX also - like controlling the number of columns, where breaks exist, etc.

Re: Using Microsoft Word with Git

#65

Post by Hackbraten »

tomashubelbauer wrote: post #23

I've mentioned this in a similar thread a few months back, but it looks like it could be relevant here, too: https://github.com/TomasHubelbauer/modern-office-git-diff I've made this script which automatically extracts the Office file format (which is a ZIP archive of XML documents) and versions the XML documents and their extracted text contents alongside the binary Office file. This is done using a Git hook and it s…

I like this approach.

One benefit of your solution over the `textconv`-based approach mentioned in the article is that your solution offers two different levels of diffs (XML and TXT).

To simulate that with textconv, you’d have to switch between two `diff.doc.textconv` variants.

Re: Using Microsoft Word with Git

#66

Post by Icathian »

michihuber wrote: post #34
codingdave wrote: post #14

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…

I agree with this being about workflows, not documents, but isn't branching and merging a workflow and storytelling tool? It allows multiple people to work in parallel (and in private). When somebody sends a pull-request eventually, they are presenting a story of changes that they want to get into the document and people can discuss them and approve them individually. (Of course, git the tool isn't necessarily suitab…

I think the issue is that parallel workflow is a bridge too far for the current legal profession. They do sequential and they like it. A tool that makes the sequential workflow better will gain more ground than one that tries to change the process whole hog.

Re: Using Microsoft Word with Git

#67

Post by wizzwizz4 »

est31 wrote: post #19
bugmen0t wrote: post #16

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 have to save, close, re-open, save, close, re-open a few times before the diffs stabilise – and even then it'll seemingly-arbitrarily rename all the tags.

I recommend having a commit hook that (somewhat) pretty-prints and line-wraps the XML – perhaps splitting on sentences too, so that adding a word doesn't proliferate all down the page. I haven't tried this, though, so it might not help. If you do, could you release the code?

Re: Using Microsoft Word with Git

#68

Post by Jasper_ »

MarcScott wrote: post #33
viraptor wrote: post #30

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 wouldn't consider myself an advanced Word user and all of my documents have needed more functionality than that.

Re: Using Microsoft Word with Git

#69

Post by andi999 »

tom1239 wrote: post #50
ghego1 wrote: post #17

Earlier quoted context omitted.

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 ema…

Actually what is so time inefficient about this workflow? Sending by email doesnt take a minute. Also it is a great way to transfer responsibility (in whose park is the ball).

Re: Using Microsoft Word with Git

#70

Post by jimmygrapes »

Icathian wrote: post #66
michihuber wrote: post #34

Earlier quoted context omitted.

I agree with this being about workflows, not documents, but isn't branching and merging a workflow and storytelling tool? It allows multiple people to work in parallel (and in private). When somebody sends a pull-request eventually, they are presenting a story of changes that they want to get into the document and people can discuss them and approve them individually. (Of course, git the tool isn't necessarily suitab…

I think the issue is that parallel workflow is a bridge too far for the current legal profession. They do sequential and they like it. A tool that makes the sequential workflow better will gain more ground than one that tries to change the process whole hog.

I have worked on several hundred of these types of contract processes in the last few years, and you are absolutely correct: sequential is where it's at for these situations. I have, however, encountered a few situations where time was an issue so I had two or three different versions out to different parties at the same time, and then merged the proposed changes where possible and sent out alternate versions where the changes differed. That process was... not fun, and could definitely use a more coherent workflow than manual merges or Word's built in merge features.
Post reply on HN