My main concern is when things don't get updated, because that leads to discoverability issues, e.g., new fields in tree-sitter.json that aren't added, and people will have no idea that they even exist. (This is not academic: tree-sitter init will create all binding fields now, but init -u won't add them to an existing file.)

So in my opinion:

• no need to output anything on init (the files on disk are "log" enough");
• no real need to output successful changes on init -u (since it is reasonable to assume that people who want change tracking work in a git repository and can just do git status and git diff);
• more concrete info (not warning) on what is changed in existing files is an improvement over the status quo.

@clason The latest commit fills in the schema and any new bindings fields (i.e. if they're missing, they'll get an explicit false instead) to tree-sitter.json. I'll have some time to take a pass on your other bullet points hopefully soon!

• no real need to output successful changes on init -u (since it is reasonable to assume that people who want change tracking work in a git repository and can just do git status and git diff);
• more concrete info (not warning) on what is changed in existing files is an improvement over the status quo.

Could you give an example to help me differentiate between these two points here?

Ah, sorry, they were not really different -- or rather, the third point was entirely separate: "all this being said, your changes are a strict improvement on the status quo so worth merging in any case" ("if you warn, warn better" ;))

Successfully created backport PR for release-0.26:

• fix(cli): increase verbosity of tree-sitter init -u updates #5188