git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Philip Oakley <philipoakley@iee.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: [PATCH 1/3] fetch: add --allow-local option
Date: Sat, 18 May 2013 17:26:01 -0500	[thread overview]
Message-ID: <CAMP44s3kyPdUZXUvG7cR8HMKXvna57t7A_ZAFD5L8mu4M4OfYA@mail.gmail.com> (raw)
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

  reply	other threads:[~2013-05-18 22:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16  7:31 [PATCH 0/3] fetch: fix '.' fetching Felipe Contreras
2013-05-16  7:31 ` [PATCH 1/3] fetch: add --allow-local option Felipe Contreras
2013-05-16  8:25   ` Ramkumar Ramachandra
2013-05-16  8:53     ` Felipe Contreras
2013-05-16  9:27       ` Ramkumar Ramachandra
2013-05-16  9:34         ` Felipe Contreras
2013-05-16  9:58           ` Ramkumar Ramachandra
2013-05-16 10:27             ` Felipe Contreras
2013-05-16 10:32               ` Ramkumar Ramachandra
2013-05-16 12:54                 ` Felipe Contreras
2013-05-16 15:58   ` Junio C Hamano
2013-05-16 16:26     ` Felipe Contreras
2013-05-16 16:38       ` Junio C Hamano
2013-05-16 16:52         ` Felipe Contreras
2013-05-16 18:04           ` Junio C Hamano
2013-05-16 23:07             ` Felipe Contreras
2013-05-16 23:24               ` Junio C Hamano
2013-05-17  0:04                 ` Felipe Contreras
2013-05-17 18:30                   ` Junio C Hamano
2013-05-18 12:25                     ` Felipe Contreras
2013-05-19  5:51                       ` Junio C Hamano
2013-05-19  6:10                         ` Felipe Contreras
2013-05-19  7:56                         ` About overzealous compatibility Felipe Contreras
2013-05-19 14:27                           ` Felipe Contreras
2013-05-18 13:12                     ` [PATCH 1/3] fetch: add --allow-local option Philip Oakley
2013-05-18 14:23                       ` Felipe Contreras
2013-05-18 20:53                         ` Philip Oakley
2013-05-18 22:26                           ` Felipe Contreras [this message]
2013-05-19  6:10                       ` Junio C Hamano
2013-05-16  7:31 ` [PATCH 2/3] fetch: switch allow-local off by default Felipe Contreras
2013-05-16  7:31 ` [PATCH 3/3] remote: disable allow-local for pushes Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMP44s3kyPdUZXUvG7cR8HMKXvna57t7A_ZAFD5L8mu4M4OfYA@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=philipoakley@iee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).