From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Sat, 18 May 2013 22:26:01 GMT
Subject: Re: [PATCH 1/3] fetch: add --allow-local option
Message-ID: <CAMP44s3kyPdUZXUvG7cR8HMKXvna57t7A_ZAFD5L8mu4M4OfYA@mail.gmail.com>
In-Reply-To: <2B281B554A864399824A4BCD613A819D@PhilipOakley>

On Sat, May 18, 2013 at 3:53 PM, Philip Oakley <philipoakley@iee.org> wrote:
> 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."

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