Learnings from the comments so far: I need to refine the positioning of lix.
Lix is not a replacement for git. Nor does it target version controlling code as the primary use case.
A better positioning might be "version control system as a library". The primary use case is embedding lix into applications, AI agents, etc. that need version control.
I need to to bed now. I have a flight to catch in 6 hours.
PS I am open to suggestions regarding the positioning!
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].
I really assumed that this was that; even calling it a universal version control system for binary files would be kind of a weird way of describing it but is plausibly a valid description for the package manager.
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 ...
Depends on the diff you render and what the plugin tracks.
In general, lix gives in API to track changes in any file format (via plugins). The "diff noise" thus depends on a) the plugin i.e. does it track them metadata? and b) what is rendered as the diff.
If the user doesn't care about seeing a diff of metadata in Excel, don't render the metadata in the diff. The latter is trivial because diffing in lix is just a SQL query.
Lix doesn't target code version control. It can be used for it. But the primary use case is embedding version control in applications. Such an application can be an AI agent that modifies files which entails the need to show what the agent did in that file e.g. tracking the changes.
Git is good enough for code. I don't think there is space to gain much market share.
Based on the product description, it seems that they don't like text, and want to deal in objects. It would feel strange if they did support a terminal, rather than a GUI.
> 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.
There is nuance between git line by line diffing and what lix does.
For text diffing it holds true that diffing is a separate layer. Text files are small in size which allows on the fly diffing (that's what git does) by comparing two docs.
On the fly diffing doesn't work for structured file formats like xlsx, fig, dwg etc. It's too expensive. Both in terms of materializing two files at specific commits, and then diffing these two files.
What lix does under the hood is tracking individual changes, _which allows rendering a diff without on the fly diffing_. So lix is kind of responsible for the diffs but only in the sense that it provides a SQL API to query changes between two states. How the diff is rendered is up to the application.
Most version control systems that are not Git support binary. In the industry you most often see Perforce P4 and Subversion being used for that purpose.
Correct. Perforce is expensive AF and is also kinda meh. They got bought by private equity and haven’t meaningfully improved it for like 15 years. But they’ve got gamedevs by the balls who don’t have an alternative. It’s unfortunate.
Yes. The tracking works via plugins to keep it generic. Here is a rough illustration:
File change -> Plugin (detects changes) -> Lix
It works surprisingly well because most standard file formats have off the shelf parsers. Parse a file format, and et voila, it is trivial to diff. Then pass on a standard schema for changes to lix and you end up with a generic API to query 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.
Holy moly. I just went to bed. Checking my phone for last time. Opening hackernews for "one last scroll" and see lix, my project, popping up here.
Going through the questions now. So much for going to bed.
Learnings from the comments so far: I need to refine the positioning of lix.
Lix is not a replacement for git. Nor does it target version controlling code as the primary use case.
A better positioning might be "version control system as a library". The primary use case is embedding lix into applications, AI agents, etc. that need version control.
I need to to bed now. I have a flight to catch in 6 hours.
PS I am open to suggestions regarding the positioning!
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].
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...
Would be interesting to see some tooling built around being a custom diff driver for a bunch of different standard formats!
I found this in my git starts: https://github.com/xltrail/git-xl?tab=readme-ov-file
And then there is also Pandoc that I guess could be helpful in this regard.
Lix is also a soft fork of the official Nix package manager implementation: https://lix.systems/
I really assumed that this was that; even calling it a universal version control system for binary files would be kind of a weird way of describing it but is plausibly a valid description for the package manager.
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 ...
Depends on the diff you render and what the plugin tracks.
In general, lix gives in API to track changes in any file format (via plugins). The "diff noise" thus depends on a) the plugin i.e. does it track them metadata? and b) what is rendered as the diff.
If the user doesn't care about seeing a diff of metadata in Excel, don't render the metadata in the diff. The latter is trivial because diffing in lix is just a SQL query.
name confusing it be
https://lix.systems/
It's nice, but it needs to support the most common file formats used in gamedev to gain enough traction.
for office files one can also unzip and zip to store them in git as plaintext
Its a pity Word doesnt open it's own OOXml export. At least Libre office has .fodt.
Looks cool, but seems kind of weird that it only works through an sdk. Should there be a cli or something?
Edit: Oh I see. Seems like their use case is embedding version control into another application.
Correct. Lix has been developed with the embedded use-case in mind.
Someone can write a CLI for it. Though, the primary use case is not code version control but embedding into applications
Git is a command line program so it feels strange that this doesn't seem to support that use case.
Hi,
I'm the creator of lix.
Lix doesn't target code version control. It can be used for it. But the primary use case is embedding version control in applications. Such an application can be an AI agent that modifies files which entails the need to show what the agent did in that file e.g. tracking the changes.
Git is good enough for code. I don't think there is space to gain much market share.
Based on the product description, it seems that they don't like text, and want to deal in objects. It would feel strange if they did support a terminal, rather than a GUI.
because its a stupid content tracker. see man git.
Weird sales pitch. I think Git is super mediocre and a VCS that supports binary files would be awesome.
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.
> 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.
There is nuance between git line by line diffing and what lix does.
For text diffing it holds true that diffing is a separate layer. Text files are small in size which allows on the fly diffing (that's what git does) by comparing two docs.
On the fly diffing doesn't work for structured file formats like xlsx, fig, dwg etc. It's too expensive. Both in terms of materializing two files at specific commits, and then diffing these two files.
What lix does under the hood is tracking individual changes, _which allows rendering a diff without on the fly diffing_. So lix is kind of responsible for the diffs but only in the sense that it provides a SQL API to query changes between two states. How the diff is rendered is up to the application.
Most version control systems that are not Git support binary. In the industry you most often see Perforce P4 and Subversion being used for that purpose.
Correct. Perforce is expensive AF and is also kinda meh. They got bought by private equity and haven’t meaningfully improved it for like 15 years. But they’ve got gamedevs by the balls who don’t have an alternative. It’s unfortunate.
It was initially hard for me to understand how this could work but it looks like there is a plugin system?
Yes. The tracking works via plugins to keep it generic. Here is a rough illustration:
File change -> Plugin (detects changes) -> Lix
It works surprisingly well because most standard file formats have off the shelf parsers. Parse a file format, and et voila, it is trivial to diff. Then pass on a standard schema for changes to lix and you end up with a generic API to query 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.
compelling problem statement. md and csv have their limit.
[dead]