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

From: "Felipe Contreras" <redacted>
Sent: Saturday, May 18, 2013 3:23 PM

On Sat, May 18, 2013 at 8:12 AM, Philip Oakley [off-list ref]
wrote:

quoted

From: "Junio C Hamano" <redacted>
Sent: Friday, May 17, 2013 7:30 PM
Subject: Re: [PATCH 1/3] fetch: add --allow-local option

[...]

quoted

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" [off-list ref] wrote:

Another trick is to use "git push":
        git push . $production_sha1:refs/heads/master

Philip