dvc: option/param consistency

[jorgeorpinel]

One thing I think we should not do as Git is to have inconsistent options (and API parameters) (e.g. git branch -D vs. git remote remove). Better consistency in command/subcommand usage decrease the learning curve and makes for an enjoyable CLI (heroku is a good example).

Here's the ones I've found after briefly checking all refs:

• add/run/import -f (DVC-file name) checkout/init/etc -f (force)
• get-url/import-url [out] vs. get/import --out vs move dst
• gc --projects REPOS – is it project or repo?
• add targets, metric diffs --targets vs. metrics ... path (or path API param)
  UPDATE: and now list url target? See address dvc list review from Jorge #3381 (comment)
• --show-json vs --show-hash/--show-url (different meaning of "show")
• --show-json vs --ascii
• Order of standard -hqv options in help output. Usually they're shown first as [-h] [-q | -v] but not always, for example remote ... [-h] [--global] [--system] [--local] [-q | -v]
• config name [value] vs dvc remote modify name option [value]
• maybe remove -p (purge) vs repro -p (pipeline)

This may seem like a polishing thing but I think it's actually best to address sooner than later, before too many users learn the existing options which makes it harder to change them. In any case, renamed options should be left hidden for some time, for legacy/scripting support.

---

Other misc. comments:

• repro --pull is specific to the run-cache.
  Should it be --pull-run-cache? See ref: exp-related updates in other to cmds, etc. dvc.org#2242 (review) (also rel Make that dvc repro --pull pulls all missing files. #4742)

[efiop]

Closing as stale.