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

> 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.