Re: [PATCH 2/6] Teach remote.c about the remote.default configuration setting.

[Junio C Hamano <gitster@pobox.com>]

marcnarc@xiplink.com writes:

> From: Marc Branchaud <marcnarc@xiplink.com>
>
> The code now has a default_remote_name and an effective_remote_name:
>
>  - default_remote_name is set by remote.default in the config, or is "origin"
>    if remote.default doesn't exist ("origin" was the fallback value before
>    this change).
>
>  - effective_remote_name is the name of the remote tracked by the current
>    branch, or is default_remote_name if the current branch doesn't have a
>    remote.
>
> This has a minor side effect on the default behavior of "git push".  Consider
> the following sequence of commands:
>
>       git config remote.default foo                 # Set default remote
>       git checkout somelocalbranch                  # Does not track a remote
>       git remote add origin ssh://example.com/repo  # Add a new "origin"
>       git push
>
> Prior to this change, the above "git push" would attempt to push to the new
> "origin" repository at ssh://example.com/repo.  Now instead that "git push"
> will attempt to push to the repository named "foo".

Hrm, is this a _minor_ side effect?

Isn't that a natural and direct consequence of "now you can set
remote.default configuration to name the remote you want to use in
place of traditional 'origin'" feature?  I think changing the
behaviour of "git push" in such a way is the point (may not be the
only but one of the important points) of this series.

> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index cb97cc1..fc17d39 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -27,10 +27,16 @@ documentation for linkgit:git-receive-pack[1].
>  OPTIONS[[OPTIONS]]
>  ------------------
>  <repository>::
> -	The "remote" repository that is destination of a push
> +	The "remote" repository that is the destination of the push
>  	operation.  This parameter can be either a URL
>  	(see the section <<URLS,GIT URLS>> below) or the name
>  	of a remote (see the section <<REMOTES,REMOTES>> below).
> +	If this parameter is omitted, git tries to use the remote
> +	associated with the currently checked-out branch.  If there
> +	is no remote associated with the current branch, git uses
> +	the remote named by the "remote.default" configuration variable.
> +	If "remote.default" is not set, git uses the name "origin" even
> +	if there is no actual remote named "origin".

This comment applies to other changes to the documentation in this
patch I didn't quote, but I think the phrasing 'even if there is no
acutual remote named "origin"' needs to be rethought, because "we
use it even if there is no such remote determined with this logic"
applies equally to branch.$name.remote, remote.default or built-in
default value of remote.default which happens to be "origin".

> diff --git a/remote.c b/remote.c
> index 6f371e0..2ebdbbd 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -47,6 +47,7 @@ static int branches_alloc;
>  static int branches_nr;
>  
>  static struct branch *current_branch;
> +static const char *default_remote_name;
>  static const char *effective_remote_name;

Coming from UNIX background, "effective" gives me an impression that
it is contrasted with "real" (i.e. there is "real remote" for the
branch, but during this particular invocation it is overridden and
"effective remote" is used instead).  Perhaps it is just me.

Something along the line of remote-name-to-use, use-remote, might
sound more natural.