Doesn’t matter, to git they are still binary files, which means it’ll check in each revision as an entirely new copy.
Comment on LPT Do it.
CCF_100@sh.itjust.works 1 month ago
docx files are actually zip archives with xml in them
MacNCheezus@lemmy.today 1 month ago
Zagorath@aussie.zone 1 month ago
Someone could probably build a tool which sits in between you and Git, which unzips the file before committing and after pulling, so Git sees the raw xml file, but you always see the zipped docx.
petersr@lemmy.world 1 month ago
Yeah, I made such a tool - and kept polishing edge cases until I gave up.
MacNCheezus@lemmy.today 1 month ago
I’m sure you could, but yes, it’s likely not worth the trouble.
refalo@programming.dev 1 month ago
a pre hook filter that beautifies and sanitizes the xml should fix that
uis@lemm.ee 1 month ago
JackbyDev@programming.dev 1 month ago
Which isn’t any different than keeping them as separate files space wise so what’s the problem?
(Other than Word having built-in versioning.)
MacNCheezus@lemmy.today 1 month ago
what’s the problem?
It’s basically just keeping a bunch of separate files but with extra steps.
JackbyDev@programming.dev 1 month ago
I would genuinely rather use git in such a scenario than not because there are plenty of other useful features over a bunch of files in a folder. Sure, obviously if the file is massive it is inconvenient, but that’s not a fair comparison because we’re comparing multiple copies “FINAL FINAL FOR REAL” in a folder anyways. There isn’t suddenly less size that way. It seems incredibly silly to describe it as “keeping files with extra steps” because people aren’t using git for space saving, they’re using it for version tracking. Everything git does is “keeping files with extra steps.”
uis@lemm.ee 1 month ago
I think you can write clean/smudge filter that will turn docx into tree(folder)
MacNCheezus@lemmy.today 1 month ago
You probably can but here’s why that’s still not gonna be all that effective.
uis@lemm.ee 1 month ago
Still better than having 30 copies of same document and forgetting which was the last one.
petersr@lemmy.world 1 month ago
Let me tell you something. I cannot tell you what company, but I have been tasked with putting Excel files in git “because they are just zip archives with xml” and it is just a disaster. Everytime you save the document it will save certain parts of the xml code in arbitrary ways (like each image is in a list and the order Og that list is random everytime), some metadata is re-written everytime like time of last modified and finally all the xml files are one single line. The git diffs are complete useless and noisy and just looking at the Excel file will cause git to consider it updated. So sure, you can use git to snapshot you Office documents… But just don’t.
lengau@midwest.social 1 month ago
If you are, like I once was, the poor fool who has to maintain a bunch of VBA macros… Extract them into files and source control those. Make a script to extract them and to put them back, and use git-lfs for the actual workbook if you need a template workbook.
Now pardon me, I need to add this to the agenda for my next therapy.
petersr@lemmy.world 1 month ago
I will join that therapy session. This is pretty much what we did, except LFS, since it was “a requirement” to also track what they layouting of the Excel file was like.
And even extracting and inserting the code was not stable. Excel will arbitrarily change the casing of “.path” to “.Path” for no reason and add and remove whitespace between functions as it see fit. It was such a pain. We also had a hard time handling unicode strings for instance containing a degree sign. And the list goes on.
PlexSheep@infosec.pub 1 month ago
Perhaps M$ does that specifically to make it hard to work with their formats? That way, tools like libre office stay not 100% compatible, preserving their market share.
oce@jlai.lu 1 month ago
Just fork git to handle zipping, formatting and ignoring metadata! Or just put your office document in the cloud and use the basic versioning it provides.