> On 22. Jul 2026, at 07:35, Gregory Casamento <[email protected]> wrote: > > As our team grows, the binary nature of .gorm files is becoming untenable. > Because Git cannot merge binary files, concurrent changes result in merge > conflicts where "the last person to merge wins."
> While we can easily read these formats, writing to them will always be > imperfect. Therefore, I propose we design a custom, project-controlled > serialization format that meets three criteria: > 1. Compositional Structure: Nested objects should reflect the actual UI > hierarchy (e.g., nesting an NSView inside an NSWindow tag). > 2. Human-Readable & Editable: This will allow clean version control and > manual merging. > 3. Project-Controlled: We dictate the schema, protecting us from external > breaking changes. Hi, This might be a bit out of left field, but is it perhaps feasible to instead have a Gorm merge tool, keeping the format? I.e. you give it a base/ours/theirs and it will merge the files with its specific structural knowledge about Gorm files (maybe even built into Gorm itself). Git already doesn’t have to use its built-in text merge, you can use whatever tool you want. I feel like generic text merge on a complex data format like UI layout even if the format is theoretically suitable for it is always going to be error-prone, especially if you aren’t an expert on reading the format (and I feel like a merge tool would be more the NeXTSTEP approach :^) ). Cheers, Katalin
signature.asc
Description: Message signed with OpenPGP
