Git can display diff between binary files using custom diff drivers:
> Put the following line in your .gitattributes file: *.docx diff=word
> This tells Git that any file that matches this pattern (.docx) should use the “word” filter when you try to view a diff that contains changes. What is the “word” filter? You have to set it up [in .gitconfig].
Yeah, this is how I would prefer to solve this problem personally, but it would be really nice to have some collection of tools that cover common binary file formats automatically instead of having to configure this manually every time.
This is really great. I read the Git config article, but I thought the image diff example was kinda lackluster. Im sure some better metrics could be extracted for a more descriptive diff.
This is great for showing diffs. To actually make git store only deltas, not entire binaries, you would need to configure "clean" and "smudge" filters for the format.
Given that docx (and xlsx) are a bunch of XML files compressed by zip, you can actually have clean diffs, and small commits.
In their 'Git is unsuited for applications' blog post[0] they also say the following:
> We currently have to clone the whole repository just to edit translation files. That is problematic for big repositories. The repository for posthog.com for example is ~680MB in size. Even though we only need translation files which would be at max 1MB in size, we have to clone the whole repository. That is also one of the reasons why git is not used at Facebook, Google & Co which have repository sizes in the gigabytes.
I get that it can be a bit complex, but Git can handle this circumstance pretty easily if you know how (or write a script for it).
For example, cloning the GIMP repo from GitLab takes me about 56 seconds and uses up 632 MB on disk, using just `git clone <repo>`.
(You can also run `git sparse-checkout init --no-cone` and then just `git sparse-checkout add *.po` to grab every .po file in the repo and nothing else)
Takes 14 seconds on my laptop and uses 59 MB of disk space, and checks out only the specified directories and their contents.
So yeah, it's not as automatic as one might like but ship a shell script to your translators and you're good to go. The 'Git can't do X' arguments are mostly untrue; it should really be 'Getting git to do X is more complicated than I would prefer' or 'Explaining how to do X is git is a pain', both of which are legitimate complaints.
I wonder how much room this leaves for unintended, not shown changes. E.g. Excel is a complex format that allows all sort of metadata and embeddings that would not always seem as cell changes ...
Hi, before you get too wedded to the name, you should be aware that there's already a major nix project called lix: https://lix.systems/.
Before clicking, I assumed this was actually a new feature of theirs that would apply nix build principles of some sort to version control of binaries.
Great semantic diffs, but does Lix actually define a merge algebra for concurrent structured edits, or are conflicts just punted back to humans? How does its SQL engine guarantee deterministic merges vs last-write-wins?
Merge algebra is similar to git with a three way merge. Given that lix tracks individual changes, the three way merge is more fine grained.
In case of a conflict, you can either decide to do last write wins or surface the conflict to the user e.g. "Do you want to keep version A or version B?"
The SQL engine is merge unrelated. Lix uses SQL as storage and query engine, but not for merges.
It seems to me that this is just an issue of diff features. Git can extended to show semantic diff of binary files and it doesn't technically need a completely new VCS.
As git became the most popular VCS right now and it continues to do so for foreseeable future, I don't think incompatibility with git is a good design choice.
I look at the page and leave without any clue as to what it actually does. Agents and AI are mentioned so I assume it might just be incoherent slop?
The person behind this boasts on Twitter, that they fired all their remote developers and used AI instead.
Judging by tweets, this project is 2-3 years in the making.
> Lix is a universal version control system that can diff any file format (.xlsx, .pdf, .docx, etc).
> Unlike Git's line-based diffs, Lix understands file structure. Lix sees price: 10 → 12 or cell B4: pending → shipped, not "line 4 changed" or "binary files differ".
How? I have a custom binary file format, how would Lix be able to interpret this?
> Lix adds a version control system on top of SQL databases that let's you query virtual tables like file, file_history, etc. via plain SQL. These table's are version controlled.
28 comments
[ 5.2 ms ] story [ 53.7 ms ] threadEdit: Oh I see. Seems like their use case is embedding version control into another application.
But then the first thing it talks about is diffing files. Which honestly shouldn’t even be a feature of VCS. That’s just a separate layer.
> Put the following line in your .gitattributes file: *.docx diff=word
> This tells Git that any file that matches this pattern (.docx) should use the “word” filter when you try to view a diff that contains changes. What is the “word” filter? You have to set it up [in .gitconfig].
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
Thanks for sharing!
> We currently have to clone the whole repository just to edit translation files. That is problematic for big repositories. The repository for posthog.com for example is ~680MB in size. Even though we only need translation files which would be at max 1MB in size, we have to clone the whole repository. That is also one of the reasons why git is not used at Facebook, Google & Co which have repository sizes in the gigabytes.
I get that it can be a bit complex, but Git can handle this circumstance pretty easily if you know how (or write a script for it).
For example, cloning the GIMP repo from GitLab takes me about 56 seconds and uses up 632 MB on disk, using just `git clone <repo>`.
In comparison, running these commands:
(You can also run `git sparse-checkout init --no-cone` and then just `git sparse-checkout add *.po` to grab every .po file in the repo and nothing else)Takes 14 seconds on my laptop and uses 59 MB of disk space, and checks out only the specified directories and their contents.
So yeah, it's not as automatic as one might like but ship a shell script to your translators and you're good to go. The 'Git can't do X' arguments are mostly untrue; it should really be 'Getting git to do X is more complicated than I would prefer' or 'Explaining how to do X is git is a pain', both of which are legitimate complaints.
[0] https://samuelstroschein.com/blog/git-limitations/
Going through the questions now. So much for going to bed.
Before clicking, I assumed this was actually a new feature of theirs that would apply nix build principles of some sort to version control of binaries.
https://lix.systems/
In case of a conflict, you can either decide to do last write wins or surface the conflict to the user e.g. "Do you want to keep version A or version B?"
The SQL engine is merge unrelated. Lix uses SQL as storage and query engine, but not for merges.
As git became the most popular VCS right now and it continues to do so for foreseeable future, I don't think incompatibility with git is a good design choice.
The person behind this boasts on Twitter, that they fired all their remote developers and used AI instead.
Judging by tweets, this project is 2-3 years in the making.
> Lix is a universal version control system that can diff any file format (.xlsx, .pdf, .docx, etc).
> Unlike Git's line-based diffs, Lix understands file structure. Lix sees price: 10 → 12 or cell B4: pending → shipped, not "line 4 changed" or "binary files differ".
How? I have a custom binary file format, how would Lix be able to interpret this?
> Lix adds a version control system on top of SQL databases that let's you query virtual tables like file, file_history, etc. via plain SQL. These table's are version controlled.
What does SQL have to do with everything?
Wow, sounds useful. Git doesn't do that out of the box.
BUT... the list of available "plugins" only has .csv,.md and json, which are things that git already handles just fine?
Can it actually diff excel and word and PDF or not?