On Wednesday, February 7, 2007 at 16:48:42 (-0800) Junio C Hamano writes:
quoted text
>Bill Lear <rael@zopyra.com> 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.

quoted text
> - 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
repository?

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"?

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

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

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

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


Bill
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html