config: rename config.local to config.private

[casperdcl]

DVC's use of the terms repo, local, global, and system doesn't quite match partially matches Git's use, and this can cause confusion.

config term	Git	DVC	notes
project (tracked)		.dvc/config	confusing, but ok
local	.git/config	.dvc/config.local	confusing, but ok
global	~/.gitconfig	~/.config/dvc/config	ok
system	/etc/gitconfig	/etc/dvc.config	ok
write/set	defaults to local (untracked)	defaults to project (tracked)	confusing, but ok
read/get	all locations	all locations	ok

Issues:

1. commands (e.g. dvc config; dvc remote list) don't expose an explicit --project functionality fixed by ref: add config --project flag and standardize the others dvc.org#2064
2. confusing: writing config is by default untracked (local) in Git but tracked (project) in DVC
3. confusing file name convention: what Git calls local is what DVC calls project
4. confusing file name convention: what DVC calls local is not what Git calls local
5. what DVC calls local is what would be manually edited by super advanced users in Git (e.g. .git/info/exclude, .git/hooks/)

Example which would be super confusing for Git users:

$ dvc remote list --local
hello      http://world
$ dvc remote list --global
$ dvc remote list --system
$ dvc remote list
hello      http://world
surprise   http://where/did/this/come/from

I'd suggest in the first instance renaming dvc config --local to dvc config --private or similar. Later (after people get used to this breaking change), consider re-adding --local but with a different meaning (i.e. repo) to match Git.

Alternatively we could just expose a new --preoject flag. That wouldn't solve the long term confusion problem caused by the Git dichotomy, but at least it would expose the same functionality. fixed by treeverse/dvc.org#2064

CC @iterative/engineering

[jorgeorpinel]

DVC's use of the terms repo, local, global, and system don't quite match Git's use, and this can cause confusion.

This is a constant discussion that I'm not sure how to get out of. Having tried to sound like Git from the beginning seems to have become a 2 edged sword. It helps with familiarity but then when you get into details things can behave very differently and there's no way around that since DVC is not Git and does very different things. Also Git is notoriously bad with consistency in its terminology so not really something we should strive to match.

[jorgeorpinel]

That said, it's a good analysis although I'm not sure I follow every detail (what's <unspecified>? what repo are we talking about?)

I'd suggest in the first instance renaming dvc config --local to dvc config --private or similar.

I can support these kinds of suggestions when we have a Git-matching term that is causing confusion among users, is there a support case for this one? We can probably considered these on a case-by-case basis. Thanks

[skshetry]

I agree with @jorgeorpinel on this one. We don't need to be consistent with Git at all.
But, I agree with you examples, we should be transparent about where the config came from.

[casperdcl]

Ok looks like people absolutely hate Git but completely agree with this issue?

I made a slight update to the issue to make the problem more focused:

DVC's use of the terms repo, local, global, and system doesn't quite match partially matches Git's use, and this can cause confusion.

:D

[jorgeorpinel]

what Git calls local is what DVC calls repo

I don't see config using the term "repo" much. It's only mentioned twice in https://dvc.org/doc/command-reference/config

I agree with the other inconsistencies.

[casperdcl]

Ah this is not about what what DVC chooses to call this, really. The main problem is it's not exposed (see the surprise http://where/did/this/come/from line which comes from the "repo"). I don't personally care whether it's called "repo" or something else. But call it something.

I'd also prefer both Git and DVC renamed --global to --user but this is besides the point.

Perhaps the first line of this issue description is still misleading - it makes it sound like a documentation/terminology issue. It's actually intended to be a bug/feature request/missing CLI API with a side note about terminology.