confused about remote branch management

confused about remote branch management

[Ross Boylan]

My local master branch is the result of a merge of upstream master and
some local changes.  I want to merge in more recent upstream work.
git pull doesn't seem to have updated origin/master, and git checkout
origin/master also doesn't seem to work.

Here's some info that may be relevant.


ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git remote -v
origin	https://github.com/emacs-ess/ESS.git (fetch)
origin	https://github.com/emacs-ess/ESS.git (push)
personal	https://github.com/RossBoylan/ESS.git (fetch)
personal	https://github.com/RossBoylan/ESS.git (push)
# I think I originally cloned from what is now the "personal" remote
# and switched names later so origin refers to upstream.
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -v
* master 8fa569c [ahead 340] merge from origin
# 340 ahead of personal is plausible, but ahead from origin seems odd
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git --version
git version 1.7.10.4
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -a
* master
  remotes/origin/S+eldoc
  remotes/origin/gretl
  remotes/origin/linewise_callbacks
  remotes/origin/litprog
  remotes/origin/master
  remotes/origin/transmissions
  remotes/personal/HEAD -> personal/master
  remotes/personal/S+eldoc
  remotes/personal/gretl
  remotes/personal/linewise_callbacks
  remotes/personal/litprog
  remotes/personal/master
  remotes/personal/transmissions
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status
# On branch master
# Your branch is ahead of 'personal/master' by 340 commits.
#
nothing to commit (working directory clean)
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout origin/master
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in
this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again.
Example:

  git checkout -b new_branch_name

HEAD is now at a33a2f9... Merge branch 'trunk'
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout master
Previous HEAD position was a33a2f9... Merge branch 'trunk'
Switched to branch 'master'
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git pull origin master
# [messages]
Not committing merge; use 'git commit' to complete the merge.
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status
# On branch master
# Changes to be committed:
# [long list]
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master
commit a33a2f9e06185a225af7d72ea3896cfd260e455e
Merge: 136742f 6b22a88
Author: Vitalie Spinu <spinuvit@gmail.com>
Date:   Mon Jan 20 00:43:30 2014 -0800

    Merge branch 'trunk'
# this was the head of origin/master BEFORE I did the pull.
# I think this means it has not been updated.
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git commit -m "merge in
upstream, probably fe7d609..8fa569c"
[master 59f6841] merge in upstream, probably fe7d609..8fa569c
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master -v
# no change

Re: confused about remote branch management

[Chris Packham]

On 23/07/14 14:49, Ross Boylan wrote:
> My local master branch is the result of a merge of upstream master and
> some local changes.  I want to merge in more recent upstream work.
> git pull doesn't seem to have updated origin/master, and git checkout
> origin/master also doesn't seem to work.
> 
> Here's some info that may be relevant.
> 
> 
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git remote -v
> origin	https://github.com/emacs-ess/ESS.git (fetch)
> origin	https://github.com/emacs-ess/ESS.git (push)
> personal	https://github.com/RossBoylan/ESS.git (fetch)
> personal	https://github.com/RossBoylan/ESS.git (push)
> # I think I originally cloned from what is now the "personal" remote
> # and switched names later so origin refers to upstream.
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -v
> * master 8fa569c [ahead 340] merge from origin
> # 340 ahead of personal is plausible, but ahead from origin seems odd
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git --version
> git version 1.7.10.4
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -a
> * master
>   remotes/origin/S+eldoc
>   remotes/origin/gretl
>   remotes/origin/linewise_callbacks
>   remotes/origin/litprog
>   remotes/origin/master
>   remotes/origin/transmissions
>   remotes/personal/HEAD -> personal/master
>   remotes/personal/S+eldoc
>   remotes/personal/gretl
>   remotes/personal/linewise_callbacks
>   remotes/personal/litprog
>   remotes/personal/master
>   remotes/personal/transmissions
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status
> # On branch master
> # Your branch is ahead of 'personal/master' by 340 commits.
> #
> nothing to commit (working directory clean)
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout origin/master
> Note: checking out 'origin/master'.
> 
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in
> this
> state without impacting any branches by performing another checkout.
> 
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again.
> Example:
> 
>   git checkout -b new_branch_name
> 
> HEAD is now at a33a2f9... Merge branch 'trunk'
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout master
> Previous HEAD position was a33a2f9... Merge branch 'trunk'
> Switched to branch 'master'
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git pull origin master
> # [messages]
> Not committing merge; use 'git commit' to complete the merge.

I think this is the relevant message. By doing a git pull you are asking
to merge the branch 'master' from the remote 'origin' into the current
branch (which happens to also be called 'master').

What I'm guessing is in "# [messages]" is something about a merge
conflict that needs resolving before the merge can be completed. There
are various ways to resolve the conflict but probably the easiest would be

  git mergetool
  git commit

I personally use have merge.tool set to kdiff3 but there are plenty of
other options.

Another option is to abort this attempt and try again (*warning* here be
dragons).

  git checkout master
  git reset --hard HEAD
  git pull

Note: git uses some heuristics to determine what to merge when you don't
specify what to pull. This should be origin/master unless
branch.master.remote and branch.master.merge are set to something weird.
This probably won't do away with the need to resolve your merge
conflicts but at least you'll be starting from a clean slate.


> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status
> # On branch master
> # Changes to be committed:
> # [long list]
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master
> commit a33a2f9e06185a225af7d72ea3896cfd260e455e
> Merge: 136742f 6b22a88
> Author: Vitalie Spinu <spinuvit@gmail.com>
> Date:   Mon Jan 20 00:43:30 2014 -0800
> 
>     Merge branch 'trunk'
> # this was the head of origin/master BEFORE I did the pull.
> # I think this means it has not been updated.
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git commit -m "merge in
> upstream, probably fe7d609..8fa569c"
> [master 59f6841] merge in upstream, probably fe7d609..8fa569c
> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master -v
> # no change
> 
> --
> 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
> 

Re: confused about remote branch management

[Ross Boylan]

I still don't know what I need to do to update origin/master in my local
repo.

Regarding Kevin's suggestion, I just tried "git fetch origin master".
It seems to have made no difference, at least judging by git show
origin/master.  I'm assuming the commit it show is  the head of the
branch.

For reasons given below, Chris's theory that there was a conflict also
doesn't seem to apply.

On Wed, 2014-07-23 at 19:40 +1200, Chris Packham wrote:
> On 23/07/14 14:49, Ross Boylan wrote:
> > My local master branch is the result of a merge of upstream master and
> > some local changes.  I want to merge in more recent upstream work.
> > git pull doesn't seem to have updated origin/master, and git checkout
> > origin/master also doesn't seem to work.
> > 
> > Here's some info that may be relevant.
> > 
> > 
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git remote -v
> > origin	https://github.com/emacs-ess/ESS.git (fetch)
> > origin	https://github.com/emacs-ess/ESS.git (push)
> > personal	https://github.com/RossBoylan/ESS.git (fetch)
> > personal	https://github.com/RossBoylan/ESS.git (push)
> > # I think I originally cloned from what is now the "personal" remote
> > # and switched names later so origin refers to upstream.
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -v
> > * master 8fa569c [ahead 340] merge from origin
> > # 340 ahead of personal is plausible, but ahead from origin seems odd
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git --version
> > git version 1.7.10.4
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git branch -a
> > * master
> >   remotes/origin/S+eldoc
> >   remotes/origin/gretl
> >   remotes/origin/linewise_callbacks
> >   remotes/origin/litprog
> >   remotes/origin/master
> >   remotes/origin/transmissions
> >   remotes/personal/HEAD -> personal/master
> >   remotes/personal/S+eldoc
> >   remotes/personal/gretl
> >   remotes/personal/linewise_callbacks
> >   remotes/personal/litprog
> >   remotes/personal/master
> >   remotes/personal/transmissions
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status
> > # On branch master
> > # Your branch is ahead of 'personal/master' by 340 commits.
> > #
> > nothing to commit (working directory clean)
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout origin/master
> > Note: checking out 'origin/master'.
> > 
> > You are in 'detached HEAD' state. You can look around, make experimental
> > changes and commit them, and you can discard any commits you make in
> > this
> > state without impacting any branches by performing another checkout.
> > 
> > If you want to create a new branch to retain commits you create, you may
> > do so (now or later) by using -b with the checkout command again.
> > Example:
> > 
> >   git checkout -b new_branch_name
> > 
> > HEAD is now at a33a2f9... Merge branch 'trunk'
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git checkout master
> > Previous HEAD position was a33a2f9... Merge branch 'trunk'
> > Switched to branch 'master'
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git pull origin master
> > # [messages]
> > Not committing merge; use 'git commit' to complete the merge.
> 
> I think this is the relevant message. By doing a git pull you are asking
> to merge the branch 'master' from the remote 'origin' into the current
> branch (which happens to also be called 'master').
> 
> What I'm guessing is in "# [messages]" is something about a merge
> conflict that needs resolving before the merge can be completed. There
> are various ways to resolve the conflict but probably the easiest would be
Here are the full deleted messages:
remote: Counting objects: 388, done.        
remote: Compressing objects: 100% (159/159), done.        
remote: Total 356 (delta 257), reused 289 (delta 190)        
Receiving objects: 100% (356/356), 59.99 KiB, done.
Resolving deltas: 100% (257/257), completed with 29 local objects.
From https://github.com/emacs-ess/ESS
 * branch            master     -> FETCH_HEAD
error: Terminal is dumb, but EDITOR unset
Not committing merge; use 'git commit' to complete the merge.

So the lack of commit was not from a conflict, just it didn't know how
to bring up an editor (I was in a bash  session under emacs).

[snip discussion of merging]
> 
> 
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git status
> > # On branch master
> > # Changes to be committed:
> > # [long list]
The list had only modified and added files; no conflicts.

Ross

> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master
> > commit a33a2f9e06185a225af7d72ea3896cfd260e455e
> > Merge: 136742f 6b22a88
> > Author: Vitalie Spinu <spinuvit@gmail.com>
> > Date:   Mon Jan 20 00:43:30 2014 -0800
> > 
> >     Merge branch 'trunk'
> > # this was the head of origin/master BEFORE I did the pull.
> > # I think this means it has not been updated.
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git commit -m "merge in
> > upstream, probably fe7d609..8fa569c"
> > [master 59f6841] merge in upstream, probably fe7d609..8fa569c
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master -v
> > # no change

Re: confused about remote branch management

[Junio C Hamano]

Ross Boylan <ross@biostat.ucsf.edu> writes:

> I still don't know what I need to do to update origin/master in my local
> repo.
>
> Regarding Kevin's suggestion, I just tried "git fetch origin master".

I think Kevin's suggestion was 'To older git, "git fetch origin
master" tells it to fetch master without updating origin/master, so
it is understandable that your origin/master was not molested'.

Either

	git fetch origin master:refs/remotes/origin/master

or if you want to be more explicit and unambiguous:

	git fetch origin refs/heads/master:refs/remotes/origin/master

should work on all versions of git.

Re: confused about remote branch management

[Ross Boylan]

On Wed, 2014-07-23 at 14:41 -0700, Junio C Hamano wrote:
> Ross Boylan <ross@biostat.ucsf.edu> writes:
> 
> > I still don't know what I need to do to update origin/master in my local
> > repo.
> >
> > Regarding Kevin's suggestion, I just tried "git fetch origin master".
> 
> I think Kevin's suggestion was 'To older git, "git fetch origin
> master" tells it to fetch master without updating origin/master, so
> it is understandable that your origin/master was not molested'.
> 
> Either
> 
> 	git fetch origin master:refs/remotes/origin/master
Great; that works.
Is that procedure supposed to be the usual way I track upstream in this
(1.7) version of git?  It seems arcane.

I had thought the usual workflow was supposed to be one of 2
alternatives, either
git checkout remotes/origin/master
git pull origin master
git checkout master
git merge remotes/origin/master
But that failed on the first step.  Or

# assuming we are on the local master branch
git fetch origin master
# and everything is updated.

Is the problem that I called the local branch with my modifications
master instead of something else?
> 
> or if you want to be more explicit and unambiguous:
> 
> 	git fetch origin refs/heads/master:refs/remotes/origin/master
> 
> should work on all versions of git.

After studying man git-fetch's discussion of the refspec parameter,
especially the second note: 

	You never do your own development on branches that appear on the right
hand side of a <refspec> colon on Pull: lines; they are to be updated by
git fetch. If you intend to do development derived from a remote branch
B, have a Pull: line to track it (i.e. Pull: B:remote-B), and have a
separate branch my-B to do your development on top of it. The latter is
created by git branch my-B remote-B (or its equivalent git checkout -b
my-B remote-B). Run git fetch to keep track of the progress of the
remote side, and when you see something new on the remote branch, merge
it into your development branch with git pull . remote-B, while you are
on my-B branch.

I'm even more confused.  Is "Pull: lines" a reference to log messages
during the fetch, a configuration file, or something else?  The docs
refer to a pull: line in $GIT_DIR/remotes, but I have no such directory.
I do have .git/config, which includes
[remote "personal"]
	url = https://github.com/RossBoylan/ESS.git
	fetch = +refs/heads/*:refs/remotes/personal/*
[branch "master"]
	remote = personal
	merge = refs/heads/master
[remote "origin"]
	url = https://github.com/emacs-ess/ESS.git
	fetch = +refs/heads/*:refs/remotes/origin/*

Ah!  branch master is associated with the personal remote; is that why
updating it from origin's master branch has no effect on origin/master?

I also don't know what the "." in "git pull . remote-B" does; the
git-pull manpage doesn't indicate it's legal as far as I can see.

Ross

Re: confused about remote branch management

[Junio C Hamano]

Ross Boylan <ross@biostat.ucsf.edu> writes:

>> Either
>> 
>> 	git fetch origin master:refs/remotes/origin/master
> Great; that works.
> Is that procedure supposed to be the usual way I track upstream in this
> (1.7) version of git?  It seems arcane.

No, and no.  The command is designed so that most of the time you
can just say "git fetch<ENTER>" without anything extra, which will
let the configured remote.*.fetch to kick in as the default refspec
to slurp updates to all the branches.  This is because the branches
of a single project are supposed to be related, and a single "git
fetch" goes over a single network connection, establishment of which
is expected to be a large overhead.  Letting a single invocation of
"fetch" to slurp updates to _all_ the branches is supposed not to be
too much overhead over grabbing updates to everything (let alone
invoking a "git fetch" per each individual branch), and is the
normal mode of operation.

A single-shot "git fetch origin master" to explicitly decline
following of everything other than 'master' *is* the special case.

And it was a very conscious design decision not to molest the remote
tracking branch when this kind of explicit command line request is
made, so that you do not lose track of what commit you _saw_ before
you ran the command.  That way "git log origin/master..FETCH_HEAD"
can be used to inspect what got changed since you fetched last time.

Over the years, with reflogs enabled for everybody, preserving the
remote tracking branches when the user does not explicitly ask to
store the result has become much less important.  For this reason,
modern Git applies, when it sees "git fetch origin master", the
configured remote.*.fetch as refmap to map the name "master",
i.e. the only branch you are fetching, to the remote tracking branch
you use to store the result, i.e. "refs/remotes/origin/master".

Re: confused about remote branch management

[Ross Boylan]

On Wed, 2014-07-23 at 16:51 -0700, Junio C Hamano wrote:
> Ross Boylan <ross@biostat.ucsf.edu> writes:
> 
> >> Either
> >> 
> >> 	git fetch origin master:refs/remotes/origin/master
> > Great; that works.
> > Is that procedure supposed to be the usual way I track upstream in this
> > (1.7) version of git?  It seems arcane.
> 
> No, and no.  
Good.  How should I handle getting updates from origin?
> The command is designed so that most of the time you
> can just say "git fetch<ENTER>" without anything extra, which will
> let the configured remote.*.fetch to kick in as the default refspec
> to slurp updates to all the branches.  This is because the branches
> of a single project are supposed to be related, and a single "git
> fetch" goes over a single network connection, establishment of which
> is expected to be a large overhead.  Letting a single invocation of
> "fetch" to slurp updates to _all_ the branches is supposed not to be
> too much overhead over grabbing updates to everything (let alone
> invoking a "git fetch" per each individual branch), and is the
> normal mode of operation.
> 
> A single-shot "git fetch origin master" to explicitly decline
> following of everything other than 'master' *is* the special case.
> 
> And it was a very conscious design decision not to molest the remote
> tracking branch when this kind of explicit command line request is
> made, so that you do not lose track of what commit you _saw_ before
> you ran the command.  That way "git log origin/master..FETCH_HEAD"
> can be used to inspect what got changed since you fetched last time.
> 
> Over the years, with reflogs enabled for everybody, preserving the
> remote tracking branches when the user does not explicitly ask to
> store the result has become much less important.  For this reason,
> modern Git applies, when it sees "git fetch origin master", the
> configured remote.*.fetch as refmap to map the name "master",
> i.e. the only branch you are fetching, to the remote tracking branch
> you use to store the result, i.e. "refs/remotes/origin/master".

For this case I think "get fetch" will attempt to retrieve from the
"personal" remote.

Will "get fetch origin" (with no other arguments) update all the
branches in origin, updating the remote tracking branches, particularly
in git 1.7?  

When I tried "git fetch origin" nothing happened (it returned
immediately with  no messages and git branch -v -a showed the same heads
as before).  It's quite possible none of the other branches have changed
since I last got them, so I don't think the exercise proves much.

Ross

Re: confused about remote branch management

[Kevin]

On Jul 23, 2014 5:11 AM, "Ross Boylan" <ross@biostat.ucsf.edu> wrote:
>
> My local master branch is the result of a merge of upstream master and
> some local changes.  I want to merge in more recent upstream work.
> git pull doesn't seem to have updated origin/master, and git checkout
> origin/master also doesn't seem to work.
>

git pull with two parameters in older versions will not update remote
tracking branches. That's because the last parameter expects a refspec
with a source and destination and you only specify a source.

Doing a git fetch will update them.

> ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git --version
> git version 1.7.10.4

Version 1.8.4 changes this behavior and will update the remote
tracking branches.

Re: confused about remote branch management

[Ross Boylan]

On Wed, 2014-07-23 at 15:09 +0200, Kevin wrote:
> 
> On Jul 23, 2014 5:11 AM, "Ross Boylan" <ross@biostat.ucsf.edu> wrote:
> >
> > My local master branch is the result of a merge of upstream master
> and
> > some local changes.  I want to merge in more recent upstream work.
> > git pull doesn't seem to have updated origin/master, and git
> checkout
> > origin/master also doesn't seem to work.
> >
> 
> git pull with two parameters in older versions will not update remote
> tracking branches. That's because the last parameter expects a refspec
> with a source and destination and you only specify a source. 
My command was "git pull origin master" so I  think it has a source as
well.
> 
> Doing a git fetch will update them. 
I thought git pull = get fetch + git merge.  Are you saying that if I
issued those 2 commands separately the result would have been different?
Ross
> 
> > ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git --version
> > git version 1.7.10.4
> 
> Version 1.8.4 changes this behavior and will update the remote
> tracking branches. 
> 
>