4 ms·

Under the hood, odt and docx files are zip files.[0] The “91%” change has nothing to do with rewriting the file; it mostly has to do with zip files and how poor

Under the hood, odt and docx files are zip files.[0] The “91%” change has nothing to do with rewriting the file; it mostly has to do with zip files and how poorly git handles binary diffing. Plaintext files are rewritten on disk every time you save them in virtually every editor and that doesn’t cause problems for git. I’ve never tried this, so take it with a heap of salt, but you might have better luck with the diffing if you developed a process that unzipped the file contents into your repo after you’re done editing it, and then zipped the contents back up with the right extension when you want to edit it again. Alternatively, you could just switch to a text-based format like rtf, as long as you don’t need any specific features from odt or docx. (EDIT: someone else mentions a promising sounding “flat xml” format, which I’ve never encountered before.) [0]: https://superuser.com/a/1356829 https://superuser.com/a/1356829

0xffff2 5y ago
>I’ve never tried this, so take it with a heap of salt, but you might have better luck with the diffing if you developed a process that unzipped the file contents into your repo after you’re done editing it, and then zipped the contents back up with the right extension when you want to edit it again. I have a current project where one of the other developers has tried this. It might work for a solo project, but with multiple developers on Windows (Excel) and Linux (Open Office), I find that Open Office feels a need to continually fuck with unrelated fields. Editing a single field in an xslx file results in changes in a dozen files in the unpacked version. Making any more complicated changes results in a diff that's impossible to manage.
- coder543 5y ago
  Do you actually mean OpenOffice, or do you mean LibreOffice? I would hope everyone is using the much more improved LibreOffice by now instead of OpenOffice. Still, interesting to hear some feedback on how well (or not) that idea has worked for some. The Flat XML option seems to be the best approach if you need to edit documents more complex than what can be represented in either markdown or rtf (rich text format).

0xffff2 5y ago

>I’ve never tried this, so take it with a heap of salt, but you might have better luck with the diffing if you developed a process that unzipped the file contents into your repo after you’re done editing it, and then zipped the contents back up with the right extension when you want to edit it again. I have a current project where one of the other developers has tried this. It might work for a solo project, but with multiple developers on Windows (Excel) and Linux (Open Office), I find that Open Office feels a need to continually fuck with unrelated fields. Editing a single field in an xslx file results in changes in a dozen files in the unpacked version. Making any more complicated changes results in a diff that's impossible to manage.

coder543 5y ago
Do you actually mean OpenOffice, or do you mean LibreOffice? I would hope everyone is using the much more improved LibreOffice by now instead of OpenOffice. Still, interesting to hear some feedback on how well (or not) that idea has worked for some. The Flat XML option seems to be the best approach if you need to edit documents more complex than what can be represented in either markdown or rtf (rich text format).