Re: [PATCH 1/3] fetch: add --allow-local option

["Philip Oakley" <philipoakley@iee.org>]

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Saturday, May 18, 2013 3:23 PM
> On Sat, May 18, 2013 at 8:12 AM, Philip Oakley <philipoakley@iee.org>
> wrote:
>> From: "Junio C Hamano" <gitster@pobox.com>
>> Sent: Friday, May 17, 2013 7:30 PM
>> Subject: Re: [PATCH 1/3] fetch: add --allow-local option
>>
>> [...]
>>
>>
>>> So when "the user" is running "git fetch" on "mywork" branch that
>>> happens to be forked from a local "master", i.e. her configuration
>>> is set as
>>>
>>> [branch "mywork"]
>>>        remote = .
>>>                merge = refs/heads/master
>>>
>>
>> Was the '.' example illustrative rather than exact. I see no case of
>> using
>> '.' in my configs. Or am I completely missing the point? (e.g. that
>> the use
>> of '.' an example of possible future usage)?
>
> % git checkout -t -b feature master
> # work
> % git rebase -i
>
> -- 
> Felipe Contreras
> --

OK, I see it (the dot '.' in the config file) now.

I've also located the documentation hidden at the end of git-config(1)
under branch.<name>.merge, even though your worked example has it
under remote not merge.
    [branch "feature"]
     remote = .
     merge = refs/heads/master

"If you wish to setup git pull so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting .
(a period) for branch.<name>.remote."

It feels as if this dwimmery(?) should also be listed in the gitcli(7)
documenation and under branch.<name>.remote in git-config(1) above it.

The use of dot '.' occured in a reply a couple of weeks ago:

Sent: Saturday, May 04, 2013 7:51 PM
Subject: Re: Pitfalls in auto-fast-forwarding heads that are not checked 
out?
"Jonathan Nieder" <jrnieder@gmail.com> wrote:
> Another trick is to use "git push":
>         git push . $production_sha1:refs/heads/master


Philip