All of
 help / color / mirror / Atom feed
From: Junio C Hamano <>
To: Bill Lear <>
Subject: Re: Git rescue mission
Date: Wed, 07 Feb 2007 16:48:42 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Bill Lear's message of "Wed, 7 Feb 2007 18:18:35 -0600")

Bill Lear <> writes:

> 2) Why does git pull do the right thing when on master, but seemingly
> changes behavior when on topic?

Because you told it to.

      %  cat .git/remotes/origin
      URL: /repos/git/project
      Pull: refs/heads/master:refs/heads/origin
      Pull: refs/heads/topic:refs/heads/topic

It tells "git pull" to drive "git fetch" to copy their master to
your origin and overwrite your topic with their topic, and then
merge their master to whatever branch you are currently on.

The sane/safe thing to do in the traditional layout (I'll talk
about non-traditional one in a second) is:

 - do your 'pull' only and always while on your 'master' and not
   anywhere else.

 - never build on a branch that appears on the RHS of ':'.

This layout is convenient when you always do fetches and pulls
while on 'master', but has burned enough people.  So what people
on the list seem to recommend is to use a separate remote layout
in the repository.

The principle is:

 * The branches you work on in the repository are kept in refs/heads/

 * Copies of branches from other repositories (it does not
   matter who is in control of them -- some of them may be your
   repository) are kept in refs/remotes/<symbolic name>.

So the current "git clone" (if you are using 1.4.4 series, you
can say "git clone --use-separate-remote") creates something
like this instead:

      URL: /repos/git/project
      Pull: refs/heads/master:refs/remotes/origin/master
      Pull: refs/heads/topic:refs/remotes/origin/topic

(git-clone from 1.5.0 does not actually make remotes/origin file
in .git/ that has the above -- it creates the moral equivalent
in .git/config).

So whatever you do the first step of "git pull", which is "git
fetch", will _not_ overwrite the current branch.

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,, after you upgrade to 1.5.0, it will
continue to do its thing (but you would want to upgrade the
fetch line).

  parent reply	other threads:[~2007-02-08  0:48 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 [this message]
2007-02-08  4:28   ` Alexander Litvinov
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:

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

  git send-email \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.