Consider removing `add` or making it an alias of `update`.

[mitchellwrosen]

We currently have separate add and update commands.

update is strictly more powerful than add – add will only add the new definitions defined in a scratch.u file to the codebase and namespace, whereas update will add those, and also the updates.

Generally speaking I think it's fine to have redundant commands, or commands with some overlapping functionality, but in this particular case, maintaining add isn't free for us. It brings its own complexity to the "slurp" algorithm that parses a scratch.u file and tries to classify its contents as adds, updates, aliases, and term-constructor conflicts.

Especially with some sort of "delete directive" and/or "alias directive" on the horizon, update is feeling like the wholemeal, declarative "do the thing in the scratch.u file" command, whereas I'm not exactly sure how add is intended to fit into the picture long term. For example, surely we don't want an analogous delete2 that applies only the delete directives in the scratch file, but not the adds nor updates – and that suggests to me we don't really want add either.

Related to #5089

[ceedubs]

FWIW I've probably written as much Unison code as anybody and outside of recreating a bug in a transcript, I can't recall the last time that I used add instead of update.

[aryairani]

Yeah we don't need a separate add and update, but we should

• continue to have a good "preview" / slurp result
• plan for having a way (again) to process a subset of the file (similar to what add <defn...> gives us now). However; this may be a pain. Probably, having a "preview" command for this would reduce the pain.

[aryairani]

It brings its own complexity to the "slurp" algorithm that parses a scratch.u file and tries to classify its contents as adds, updates, aliases, and term-constructor conflicts.

This is not part of whether add and update commands are separate though, this is more about whether the user should consider them separate outcomes or not.