6 ms·

> Because Excel is not a source file. Well, it is a zip-archive with XML files, so it's close.

cxr 5y ago
I recommended exploring this approach here <https://news.ycombinator.com/item?id=27998733 https://news.ycombinator.com/item?id=27998733>: > Hot tip for handling office file formats or anything that uses a ZIP container: just unzip them and commit _that_ to the repo. Even modern (zipped XML-based) office file formats do make some limited use of binary blobs. You can either keep these intact, or write a small objdump-like tool that serializes them to text†. For portability, it might be best to write the serializer/deserializer in JS dumped into a thin HTML wrapper, so you pretty much anyone can double click to "run" it. (My experiments on roundtrippability with including that file in the ZIP container yielded poor results.) † I've used this strategy for Oberon .rsc binaries. Due to Wirth's affinity for single-pass compilers, the Oberon toolchain doesn't involve a discrete assembler or AOT linker tool, so there is no assembly format or linker scripts. However, Wirth's distribution of the Oberon system does have an ORTool utility <https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/ORTool.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/ORToo...> (in the vein of objdump/readelf/nm) that will dump a textual description of the binary you give it. I realized that with some slight tweaks, you can use the output of ORTool.DecObj as a de facto "assembly" format—just write a tool capable of parsing it and then write out the corresponding binary.
- inshadows 5y ago
  >> Hot tip for handling office file formats or anything that uses a ZIP container: just unzip them and commit _that_ to the repo. What is the point if that? I think neither binary nor XML output would be meaningful in the diff output.
WorldMaker 5y ago
I built a tool to explore version control of files like that by decompressing their contents and version controlling those. It was an interesting experiment.
banana_giraffe 5y ago
Notably: The VBA stuff is stored as a binary OLE2 blob thing inside of the xlsm file. (Or at least it is in the few spreadsheets I checked, no clue if there's some way to change that behavior)
- tyingq 5y ago
  The VBA blob is documented: https://interoperability.blob.core.windows.net/files/MS-OVBA/%5bMS-OVBA%5d.pdf https://interoperability.blob.core.windows.net/files/MS-OVBA... 111 pages, and it looks non-trivial to implement something to tear it apart. But, I give MS some credit for documenting it.

cxr 5y ago

I recommended exploring this approach here <https://news.ycombinator.com/item?id=27998733 https://news.ycombinator.com/item?id=27998733>: > Hot tip for handling office file formats or anything that uses a ZIP container: just unzip them and commit _that_ to the repo. Even modern (zipped XML-based) office file formats do make some limited use of binary blobs. You can either keep these intact, or write a small objdump-like tool that serializes them to text†. For portability, it might be best to write the serializer/deserializer in JS dumped into a thin HTML wrapper, so you pretty much anyone can double click to "run" it. (My experiments on roundtrippability with including that file in the ZIP container yielded poor results.) † I've used this strategy for Oberon .rsc binaries. Due to Wirth's affinity for single-pass compilers, the Oberon toolchain doesn't involve a discrete assembler or AOT linker tool, so there is no assembly format or linker scripts. However, Wirth's distribution of the Oberon system does have an ORTool utility <https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/ORTool.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/ORToo...> (in the vein of objdump/readelf/nm) that will dump a textual description of the binary you give it. I realized that with some slight tweaks, you can use the output of ORTool.DecObj as a de facto "assembly" format—just write a tool capable of parsing it and then write out the corresponding binary.

inshadows 5y ago
>> Hot tip for handling office file formats or anything that uses a ZIP container: just unzip them and commit _that_ to the repo. What is the point if that? I think neither binary nor XML output would be meaningful in the diff output.

WorldMaker 5y ago

I built a tool to explore version control of files like that by decompressing their contents and version controlling those. It was an interesting experiment.

banana_giraffe 5y ago

Notably: The VBA stuff is stored as a binary OLE2 blob thing inside of the xlsm file. (Or at least it is in the few spreadsheets I checked, no clue if there's some way to change that behavior)

tyingq 5y ago
The VBA blob is documented: https://interoperability.blob.core.windows.net/files/MS-OVBA/%5bMS-OVBA%5d.pdf https://interoperability.blob.core.windows.net/files/MS-OVBA... 111 pages, and it looks non-trivial to implement something to tear it apart. But, I give MS some credit for documenting it.