All of
 help / color / mirror / Atom feed
From: Bill Lear <>
To: Junio C Hamano <>
Subject: Re: Git rescue mission
Date: Thu, 8 Feb 2007 09:27:32 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wednesday, February 7, 2007 at 16:48:42 (-0800) Junio C Hamano writes:
>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.

This I understand, and can follow.  Sorry, but there my comprehension
stops.  Lots of confusion and befuddlement follow.  Thank you in
advance for being patient.

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

This I don't quite understand.  So, if it is on the LHS, it is ok?
But, if it is ALSO on the RHS it is not?

So, this:

      Pull: refs/heads/topic:refs/heads/topic

really means don't don't work on a branch named topic in this

I assume by "build on" you mean "work, compile, check stuff in,
etc."?.  Did you have something else in mind when you said "build on"?

>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>.

I don't currently have any 'refs/remotes' of any sort, so I guess you
mean that the new principle, using git clone --use-separate-remote
will effect this.

>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, using 1.4.4 series, or 1.5, the "sane" way to work in git
is to use clone --use-separate-remotes.

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

I assume by this you mean that if I do the separate remote trick, I
will not shoot myself by doing a 'git pull' while on my topic branch,
as the setup will cause git to refuse to do it.

>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).

Ok, so if I am on master, I do this:

[master] % git pull

and this will fetch the remote master and merge it to my master, and
fetch the remote topic and merge it to my local topic.

While, if I am on my topic branch, if I do this:

[topic] % git pull

it sill fetches from the remote master and the remote topic, but will
not merge at all.

Could you verify if I have stated your position correctly?

If I am, this still seems bizarre.  I really just want a way to sync
two repos that works consistently, and is invoked consistently, no
matter what branch I am currently on.  And, again, by "sync", I just
mean no cross-branch merging --- no "crossing of the streams".  Even
if it were limited to syncing the current branch only, that would be
ok, but this variable behavior seems rather odd and confusing.  In
other words, I just want to type the equivalent of 'git sync' and have
it work, and not have to give a branch name, or be in the "right
place" for it to work as I expect.

Thus, I don't want to have to think "oh, I'm on my topic branch, and
if I really want to sync from my remote repo, I need to get on my
master branch".  It seems that the only difference in the "insane" way
I was doing things and the "sane" way you propose is that in my way, I
had to make this mental leap or get burned by a cross-branch merge,
but in the new way, I still have to make this mental leap if I want it
to work, but if I don't, at least I don't get burned.


  parent reply	other threads:[~2007-02-08 15:27 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
2007-02-09  0:53     ` Junio C Hamano
2007-02-09  3:32       ` Alexander Litvinov
2007-02-08 15:27   ` Bill Lear [this message]
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.