Jonathan Nieder <jrnie...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
