Experiments default git remote

[dberenbaum]

See the discussion in #6332 (comment) for background.

Some benefits to having a default git remote in experiments:

1. It's easier for the user to not have to explicitly configure the git remote in simple scenarios. This can be especially confusing since pushing experiments requires both a git and a dvc remote, one of which has a default. Understanding both types of remotes, how experiments use them, and which one takes a default is asking a lot of users.
2. It's consistent with other dvc and git commands.

The downside to a default git remote is that it could result in unexpected behavior. In particular, since experiments do not have upstream tracking branches, any branch-specific tracking branches set in Git will be ignored. See #6332 (comment). More generally, if users need to push to a non-default branch but aren't aware of the default behavior in dvc, they could accidentally push to an unwanted remote if dvc doesn't require it to be set explicitly.

There are a few options for a default git remote in experiments:

1. Use git defaults. This could be misleading for tracking branches as mentioned above.
2. Use origin by default. This requires documenting the behavior and might be unexpected for users who are generally pushing code to non-origin remotes.
3. Clone [--bare] to the dvc remote and push there instead of the user's git remote. This option hasn't been discussed, so curious to hear thoughts on it.

@karajan1001 @pmrowla

[pmrowla]

I would still prefer that we just require the user to be explicit when specifying where to push exp refs. We can add a way for users to explicitly set a default git remote, but the fallback behavior for DVC should be to error out if no git remote has been explicitly specified by the user (either through the existing behavior or this new config option).

Clone [--bare] to the dvc remote and push there instead of the user's git remote.

Creating a bare git repo on a DVC remote would only work for local and SSH remotes. I think it would also be non-intuitive, since your exp git refs would be pushed to a different git remote than everything else in your git repo. The whole point of the way that the exp feature works is so that they can be treated exactly the same as the other commits and refs in your git repo.

This would be like if github stored your actual git server repo in one location (github.com/my/repo.git) but for some reason pull request refs were stored in a completely separate server repo (github.com/my/repo-pull-request-refs.git). It just doesn't make sense with regard to how git refs work - exp refs/GH PRs/regular branches/tags/etc are all references to the same commits within a single git repo. They aren't references to commits in separate git repos.

[karajan1001]

Yes the logic of a default remote in git is much more granular than ours. But what would they do if? a new branch ( like what in dvc exp ) was pushed without specifying a remote?

[pmrowla]

git defaults to origin if nothing is specified

(the issue with using this behavior in DVC is that we would default to origin for all experiments, even if the user has set something other than origin to be used as the default for a specific git branch which will lead to unexpected/confusing behavior #6332 (comment))