From: Junio C Hamano <gitster@pobox.com>
To: Miles Bader <miles@gnu.org>
Cc: git@vger.kernel.org
Subject: Re: "git pull REMOTE" question
Date: Tue, 21 Aug 2007 22:11:49 -0700 [thread overview]
Message-ID: <7vtzqsjgq2.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <buo8x84kwkq.fsf@dhapc248.dev.necel.com> (Miles Bader's message of "Wed, 22 Aug 2007 13:44:05 +0900")
Miles Bader <miles.bader@necel.com> writes:
> This apparent association of each local branch with a single remote
> seems slightly odd to me
I share the feeling. I think pulling from more than one remote
is the norm, and moreover, pulling from more than one branch of
one remote (depending on which branch you are pulling into) is
also common. I did not even want to have the "when we are on
this branch we would pull from that branch of that remote" we
currently have to begin with, but this is what the list wanted,
so there you are.
I _think_ the right approach is:
git pull remote_name
when the user does not tell git which branch he is interested in
merging should be to say:
1. Do we have an association of our current-branch and the
remote name that defines which branch to merge? If so, use
it (we do not have this right now, except for the case where
remote_name matches branch.$current_branch.remote);
2. Do we have a map from (current-branch, remote_name) to the
branch to be merged? If so, use it (we do not have this
right now).
3. Is there the primary branch remote side defines (aka
refs/remotes/remote_name/HEAD)? If so, use it (we do not do
this at all);
So, how about extending the syntax for [branch $current_branch]
section of the config like this?
;; traditional -- when on "master", use '[remote "origin"] url'
;; and '[remote "origin"] fetch' to decide where to fetch from,
;; and merge their refs/heads/master to our branch.
[branch "master"]
remote = origin
merge = refs/heads/master
;; new -- when on "master', and the user says to pull from "usb"
;; without saying which branch to merge, use '[remote "usb"] url'
;; and '[remote "usb"] fetch' to decide where to fetch from,
;; and merge their refs/heads/xprm to our branch.
[branch "master:usb"]
merge = refs/heads/xprm
The trick in the new syntax is that you cannot have a colon in
refname, so there is no way for existing [branch $name] section
to crash with the new style definition.
next prev parent reply other threads:[~2007-08-22 5:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-22 4:23 "git pull REMOTE" question Miles Bader
2007-08-22 4:35 ` Junio C Hamano
2007-08-22 4:44 ` Miles Bader
2007-08-22 5:11 ` Junio C Hamano [this message]
2007-08-22 16:44 ` Jon Loeliger
2007-08-22 20:29 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vtzqsjgq2.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=miles@gnu.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.
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 NNTP newsgroup(s).