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

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