Ignition 8.3 and Git-Friendliness – Remaining Challenges

Ignition
1

Hi,

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.

  • Reduce non-functional churn in resource.json.

  • Improve determinism in file generation (stable ordering, minimal metadata changes, etc.).

The improvements so far are appreciated — but there is still work to be done before Ignition projects behave like first-class Git repositories.

Curious to hear how others are handling this, and whether there are roadmap items addressing these remaining issues.

2 Likes