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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2012, 19:31 UTC
Message-ID: <7vhatkofe6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FF6F805.20403@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 12 quoted lines

> On 12-07-05 06:50 PM, Junio C Hamano wrote:
>> 
>>>  - 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.
>> 
>> The explanation of the latter belongs to the previous step, I think.
>> I am not sure if "effective" is the best name for the concept the
>> above explains, though.
>
> Well, the previous commit removes default_remote_name, so the explanation
> wouldn't be valid verbatim.

The previous one introduces "effective" (which I still think is not the best word for the semantics you are trying to give to the variable) without explaining what the variable is for and justifying why "effective" is the right word (or at least a better than "default") for it. Something like the "- effective_remote_name is the ..." above is necessary in its commit log message.

Show 7 quoted lines

> How about keeping the above here, and I could add the following to the
> previous commit's message:
>
> 	effective_remote_name is the remote name that is currently "in
> 	effect".  This is the currently checked-out branch's remote, or
> 	"origin" if the branch has no remote (or the working tree is a
> 	detached HEAD).

Yeah, along that line.

> The read_config() function already has logic to avoid re-parsing the entire
> config over and over again.  There are many places in remote.c that call
> read_config(), and I thought I was just following that pattern.

OK.