From: Alexander Litvinov <litvinov2004@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Git rescue mission
Date: Thu, 8 Feb 2007 10:28:31 +0600 [thread overview]
Message-ID: <200702081028.31493.litvinov2004@gmail.com> (raw)
In-Reply-To: <7vr6t13251.fsf@assigned-by-dhcp.cox.net>
> In order to prevent merging their 'master' into your 'topic'
> when you are on 'topic', git-fetch/git-pull from 1.5.0 uses
> further safety which is left by 'git clone'. The real
> configuration created by 'git clone' looks like this:
>
> [remote "origin"]
> url = /repos/git/project
> fetch = refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> The 'fetch' lines correspond to 'Pull' in .git/remotes/origin file;
> it uses globbing pattern so if there are new branches on the
> remote side you can automatically track them, which is a plus.
>
> But more importantly, when 'fetch' lines only do the globbing
> pattern, 'git pull' without explicitly saying which remote
> branch you want to merge to the current branch (perhaps by
> mistake) refuses to do a merge, if there is no branch.*.merge
> configuration ("refs/heads/master" in the above example). So
> with the above configuration, 'git pull' from 1.5.0 will fetch
> two remote branches and keep them in remotes/origin/master and
> remotes/origin/topic, and if you are on 'master' their
> refs/heads/master is merged into your current branch, but if you
> are on 'topic', it will not do the merge step (this only applies
> to "git pull" without any refspec parameters).
>
> With 1.4.4 series, I think you can create the [branch] section
> yourself and do something like this:
>
> [remote "origin"]
> url = /repos/git/project
> fetch = refs/heads/master:refs/remotes/origin/master
> fetch = refs/heads/topic:refs/remotes/origin/topic
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [branch "topic"]
> remote = origin
> merge = refs/heads/topic
>
> This configuration also works with 1.5.0, so if you are happy
> with this (I am assuming you are using 1.4.4 series, preferably
> the last one, 1.4.4.4), after you upgrade to 1.5.0, it will
> continue to do its thing (but you would want to upgrade the
> fetch line).
I think this should go to git-pull/git-clone man pages. Personaly for me this
post dispels dark magic about git-pull's merging logic. I always did
git-fetch and then git-pull . <some-branch> to control what and where should
be merged.
next prev parent reply other threads:[~2007-02-08 4:28 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 0:18 Git rescue mission Bill Lear
2007-02-08 0:22 ` Johannes Schindelin
2007-02-08 0:24 ` Bill Lear
2007-02-08 0:25 ` Johannes Schindelin
2007-02-08 0:34 ` Bill Lear
2007-02-08 0:48 ` Junio C Hamano
2007-02-08 4:28 ` Alexander Litvinov [this message]
2007-02-09 0:53 ` Junio C Hamano
2007-02-09 3:32 ` Alexander Litvinov
2007-02-08 15:27 ` Bill Lear
2007-02-08 15:56 ` Jakub Narebski
2007-02-08 23:24 ` Jeff King
2007-02-08 23:32 ` Bill Lear
2007-02-08 17:27 ` Linus Torvalds
2007-02-08 20:12 ` Kalle Pokki
2007-02-08 21:23 ` Linus Torvalds
2007-02-08 22:03 ` Kalle Pokki
2007-02-08 22:10 ` Shawn O. Pearce
2007-02-09 1:48 ` Theodore Tso
2007-02-09 1:58 ` Shawn O. Pearce
2007-02-09 2:01 ` Jakub Narebski
2007-02-10 16:05 ` Theodore Ts'o
2007-02-10 16:05 ` [PATCH] Print a sane error message if an alias expands to an invalid git command Theodore Ts'o
2007-02-10 16:05 ` [PATCH] Allow aliases to expand to shell commands Theodore Ts'o
2007-02-10 18:04 ` Linus Torvalds
2007-02-10 18:13 ` Theodore Tso
2007-02-10 20:34 ` Johannes Schindelin
2007-02-11 0:13 ` Theodore Tso
2007-02-11 16:03 ` Johannes Schindelin
2007-02-11 16:21 ` Theodore Tso
2007-02-11 16:36 ` Johannes Schindelin
2007-02-11 21:44 ` Junio C Hamano
2007-02-11 22:03 ` Johannes Schindelin
2007-02-12 3:56 ` Theodore Tso
2007-02-12 6:53 ` Shawn O. Pearce
2007-02-10 16:50 ` [PATCH] Print a sane error message if an alias expands to an invalid git command Junio C Hamano
2007-02-09 19:21 ` Git rescue mission Kalle Pokki
2007-02-08 21:57 ` Bill Lear
2007-02-08 22:13 ` Linus Torvalds
2007-02-08 22:33 ` Bill Lear
2007-02-08 23:25 ` Bill Lear
2007-02-08 23:33 ` Shawn O. Pearce
2007-02-08 23:40 ` Bill Lear
2007-02-08 23:50 ` Shawn O. Pearce
2007-02-09 0:03 ` Jakub Narebski
2007-02-09 0:17 ` Linus Torvalds
2007-02-09 8:58 ` Michael S. Tsirkin
2007-02-08 23:38 ` Jakub Narebski
2007-02-08 23:46 ` Linus Torvalds
2007-02-09 4:38 ` Junio C Hamano
2007-02-08 22:29 ` Jakub Narebski
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=200702081028.31493.litvinov2004@gmail.com \
--to=litvinov2004@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).