threads / discuss / 37193

confused about remote branch management

Subject: confused about remote branch management

## tl;dr

9 messages between Jul 23, 2014 and Jul 24, 2014.

replies: 8people: 4as markdown or json

Ross Boylan· Jul 23, 2014, 02:49 UTC · lore

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
Chris Packham· Jul 23, 2014, 07:40 UTC · re: Ross Boylan · lore

Re: confused about remote branch management

On 23/07/14 14:49, Ross Boylan wrote:
Show 61 quoted lines
> 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.
Show 24 quoted lines
> 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
>
Ross Boylan· Jul 23, 2014, 19:22 UTC · re: Chris Packham · lore

Re: confused about remote branch management

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:
Show 70 quoted lines
> 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]
Show 6 quoted lines
> 
> 
> > 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
Show 14 quoted lines
> > 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
Junio C Hamano· Jul 23, 2014, 21:41 UTC · re: Ross Boylan · lore

Re: confused about remote branch management

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.
Ross Boylan· Jul 23, 2014, 23:30 UTC · re: Junio C Hamano · lore

Re: confused about remote branch management

On Wed, 2014-07-23 at 14:41 -0700, Junio C Hamano wrote:
Show 14 quoted lines
> 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?

Show 6 quoted lines
> 
> 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
Junio C Hamano· Jul 23, 2014, 23:51 UTC · re: Ross Boylan · lore

Re: confused about remote branch management

Ross Boylan <ross@biostat.ucsf.edu> writes:
Show 6 quoted lines
>> 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".

Ross Boylan· Jul 24, 2014, 00:24 UTC · re: Junio C Hamano · lore

Re: confused about remote branch management

On Wed, 2014-07-23 at 16:51 -0700, Junio C Hamano wrote:
Show 10 quoted lines
> 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?
Show 28 quoted lines
> 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
Kevin· Jul 23, 2014, 13:30 UTC · re: Ross Boylan · lore

Re: confused about remote branch management

On Jul 23, 2014 5:11 AM, "Ross Boylan" <ross@biostat.ucsf.edu> wrote:
Show 6 quoted lines
>
> 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.

Ross Boylan· Jul 23, 2014, 18:54 UTC · lore

Re: confused about remote branch management

On Wed, 2014-07-23 at 15:09 +0200, Kevin wrote:
Show 14 quoted lines
> 
> 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

Show 8 quoted lines
> 
> > 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. 
> 
>

← back to recent threads