CUE documentation should talk about whether terser diffs are selling point

[paul-hammant]

You know, like what git-diff would say about an item added to a list - how many lines does the underlying diff engine think has changed

[xinau]

Thanks for your suggestion. I think it would be a good idea to add this feature to the documentation once #8 is implemented :)

[paul-hammant]

I don't think so. This is a function of Git, Mercurial, Svn, Perforce, PlasticSCM. How pretty are diffs in that tech (unified diff really), for a number of change scenarios. And I say that becuase the at-rest format for CUE things is carriage-return delimited text (UTF8, or a codepage, etc), is it not??

[xinau]

@paul-hammant could you please elaborate a little bit more and provide an example on your issue/request as I'm struggling to understand the underlying issue.

[paul-hammant]

$> diff ABCv1.toml ABCv2.toml

What does that diff look like (but CUE source not .txt files)? Is it noisy for a given scenario, or terse? If XML is OK for diffs (for that scenario). JSON is noisy because of the commas. What does CUE diffs look like?

[myitcv]

Thanks for raising this point @paul-hammant - I've converted your original issue to a discussion for better visibility.

[myitcv]

To answer your question with a couple of specific points, @paul-hammant.

Commas are required between list elements, but when a list is split across multiple lines cue fmt automatically adds a trailing , to the last element. For example:

x: [
	1,
	2,
	3
]

would automatically be converted to:

x: [
	1,
	2,
	3,
]

LSP support will bring auto-formatting to all LSP-enabled editors.

CUE also has an internal package for calculating semantic diffs between configurations. We have recently discussed how that might be surfaced as a subcommand of cmd/cue. That would be a building block for using such a tool as an alternative git diff tool.

[cueckoo]

This discussion has been migrated to cue-lang/cue#832.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.