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

On Sat, May 18, 2013 at 3:53 PM, Philip Oakley [off-list ref] wrote:

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

quoted

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

This is called the upstream branch. Go to any branch, and do this:

% git checkout feature
% git branch --set-upstream-to master

And it would set:

  remote = .
  merge = refs/heads/master

Now you can do things like:

% git log feature@{upstream}..feature

Which gets translated to:

% git log master..feature

And:

% git rebase -i

Which gets translated to:

% git rebase -i master

This is nothing new.

-- 
Felipe Contreras