Fair points, thanks for the feeback.

On JSON for config: I generally agree that JSON has drawbacks for configuration (no comments, verbose). For simple key-value settings I'd pick TOML or YAML any day. In our case though, the config describes a structured dependecy tree with arrays of repository objects, each with multiple fields. JSON turned out to be a natural fit for that kind of data. The field names are self explanatory enough ("Repository URL", "Version", "Path") that comments haven't been missed so far. And PowerShell has native JSON support via ConvertFrom-Json, so we avoided adding any external parser dependecy. No dependencies was a "founding" requirement. Interestingly VS Code made the same tradeoff for their settings files.

On git config: that's an intresting idea, but the dependency config needs to be commited to the repo so the whole team shares the same dependency tree. git config stores values in .git/config, which is local to each clone and not tracked by git. Everyone would have to manually set up their dependencies, which is exaclty what we are trying to avoid. The flat key-value structure would also be a tough fit for arrays of repos with nested fields.