First of all, I appreciate the continued focus on making Ignition 8.3 more Git-friendly. The direction is absolutely correct, and the improvements compared to earlier versions are noticeable.
That said, there are still some structural issues that make clean Git workflows difficult in practice.
1. Binary Changes for Simple Configuration Updates
There are still project-level changes that result in updates to binary files.
For example:
Changing the default provider updates:
ignition/global-props/data.bin
This makes it impossible to review changes in a meaningful way. A simple configuration adjustment results in a binary diff, which:
Cannot be reviewed in pull requests
Cannot be merged cleanly
Creates unnecessary conflicts in multi-developer environments
If Ignition aims to be truly Git-native, project configuration changes should ideally be represented in text-based, diffable formats.
2. Excessive Noise in resource.json Files
The resource.json files generate a significant amount of Git noise.
Even small or seemingly unrelated changes can produce large diffs in these files. This makes it harder to:
Identify the actual functional change
Review pull requests efficiently
Maintain clean commit histories
In larger teams, this becomes a real friction point. The signal-to-noise ratio is still too low.
Constructive Challenge
If 8.3 is positioned as “Git-friendly,” I would challenge IA to take this one step further:
Eliminate remaining binary project-level dependencies where feasible.
You can just write your own posts, you don't need to have LLMs triple your word count
is internal issue IGN-1061; the global-props resource is a bit of legacy baggage we haven't paid down yet and controls a too-wide swath of functionality that we're planning to split up into a few different resources with a human readable encoding. In general, the trend throughout Ignition is towards human readable/diffable formats on disk, but we're also balancing that with the commitment to stability. Untouched code is generally safer - the more you change, the more risk you introduce.
Is hard to quantify (I suspect because your LLM obscured your original meaning too much). Can you provide actual examples of the "large diffs" you're seeing in these files?
All that to say: We're not unaware that the VCS experience isn't first class. We're always working to improve it. But specific points of friction (like the global-props resource) are much more useful than "improve determinism", because the immediate followup is where?
Busted. There’s no doubt in the world that this is LLM text. The original post took me exactly 10 seconds to post, though...
Large diffs is not a good description, lets blame the LLM for that. It’s rather the amount of resource.json files generated by small changes — or no changes at all. Editing views causes them, of course, but also just opening the view inside the Designer.
I renamed one realtime tag provider, just added one letter to its name. Since folders change name, a lot of files are deleted and tags with new paths added. But also thousands of resource.json files.
That's also an internal ticket (IGN-12564). Each workspace/resource type needs to do its own calculation of "did anything meaningful change in this view between now and when it was last saved", and in Vision and Perspective that's not trivial to answer, because of things like bindings updating timestamps of serialized values. But not impossible.
Well, have you tried not doing that?
More concretely - what could we do differently? The contents of these resource.json files shouldn't be different, so it's on the VCS to recognize it as a move rather than a delete and recreate.
If their contents aren't the same, then that's definitely a bug and something we can address.
The presence of the resource.json file is what creates the resource.
Without that file, we don't "know" where the other files in the resource are.
Sure, for views you can assume "oh, well just look for a file in the directory named view.json" - but:
That would require us to, somehow, dictate what files are 'associated' with a resource (declaratively) and pass that information from way down in subsystems like Perspective all the way up to core platform configuration manager classes.
That completely eliminates the possibility of any kind of 'dynamic' resource. Case in point: Translations. In 8.3, translation manager translations are stored as one data file per locale - e.g. en_US.json, es_MX.json. If we didn't have a declarative manifest of files to 'know' which locales we have translations for, we'd have to ask the underlying filesystem to browse - multiplied by each resource under each resource type, that would be incredibly slow.
Which is not to say that it's impossible. Certainly, in another timeline we could have structured the way Ignition stores its resources differently. But you're going to want to store metadata somewhere, and having a declarative manifest of files right next to things turns out to be pretty convenient.
All that said,
This is one that bugs me personally. I think we do need, in the short term, a way for systems like Perspective to mark a file as "optional" more clearly. You already can remove the thumbnail.png and as far as I know the designer will happily continue along and regenerate it the next time you open the view. The problem is that removing the thumbnail changes the signature, which makes the system want to generate a new resource.json write.
Like I said in the beginning - we're aware that the VCS experience is not ideal. It's high on my list of personal gripes. But while it's "good enough" it's hard to get internal motivation to make sweeping, risky changes that could spill over to the folks who are not using VCS systems in a negative way.
