Re: [RFC/PATCH 1/2] config doc: add dot-repository note
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 20, 2013, 17:50 UTC
- Message-ID
- <7v7gitwneq.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130519174307.GC3362@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 12 quoted lines
> 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 myworkAlso 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.