Re: [RFC/PATCH 1/2] config doc: add dot-repository note

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

Jonathan Nieder <jrnieder@gmail.com> writes:

> Philip Oakley wrote:
>
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -734,6 +734,8 @@ branch.<name>.remote::
>>  	overridden by `branch.<name>.pushremote`.  If no remote is
>>  	configured, or if you are not on any branch, it defaults to
>>  	`origin` for fetching and `remote.pushdefault` for pushing.
>> +	Additionally, a `.` (period) means the current local repository
>> +	(a dot-repository), see `branch.<name>.merge`'s final note below.
>
> Does this accept an arbitrary git URL, or only remote names?

The branch.<name>.remote variable refers to remote names, and '.'
often appears as a special name to refer to the local repository.

I think you can define it as URL and your "git fetch" (no args) will
do the right thing in that it would:

 (1) fetch the history leading to the tip branch.<name>.merge branch
     from there; and

 (2) leave the result in FETCH_HEAD, so that "git merge FETCH_HEAD"
     can conclude the "git pull" you split into two manually by
     running "git fetch" first,

but I do not think there is a "while we create this branch" side
effect UI like "--set-upstream-to" for doing so, except for setting
it to '.' when you set upstream to a branch in the local repository.
I.e.

	git checkout -t -b mywork master
        git branch --set-upstream-to master mywork

Also I think setting it to arbitrary URL would mean that you would
not see any remote tracking ref (they are to be defined as a
property of named remote with remote.<name>.fetch refspecs), so it
is unclear how @{u} would work.  @{u} works when the variable is set
to '.', though.

For the above reasons, describing '.' as a special value for the
variable that the end users are likely to see is a reasonable "white
lie" for this part of the documentation.