Skip to contentSkip to conversation

confused about remote branch management

DISCUSSION Ross Boylan 4 participants 9 messages Jun 15, 2016 1 message not in the archive

lore
Share & tools
lore

Ross Boylan

author
#0 lore raw

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 <[email protected]>
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
#1 lore raw
Quoted 54 lines · 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

Quoted 7 lines

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.

Quoted 24 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 <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#2 lore raw

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.

Quoted 63 lines · Chris Packham
Quoted 54 lines · 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

Quoted 7 lines

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

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]

Quoted 6 lines
Quoted 6 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

Quoted 14 lines
Quoted 14 lines
ross@tempserver:~/UCSF/Choi/GitHub/ESS$ git show origin/master
commit a33a2f9e06185a225af7d72ea3896cfd260e455e
Merge: 136742f 6b22a88
Author: Vitalie Spinu <[email protected]>
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
#3 lore raw
Quoted 4 lines · 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".

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.

author
#4 lore raw
Quoted 7 lines · Junio C Hamano
Quoted 4 lines · 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".

Quoted 7 lines

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?

Quoted 6 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

#5 lore raw
Quoted 6 lines · Ross Boylan
Quoted 3 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".

author
#6 lore raw
Quoted 10 lines · Junio C Hamano
Quoted 6 lines · Ross Boylan
Quoted 3 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.

Good. How should I handle getting updates from origin?

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

Quoted 7 lines

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

#7 lore raw
In reply to Ross Boylan
Quoted 6 lines · 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.

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.

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

A message that is not in the archive (sent off-list or not yet received): CAO54GHBEexASvZcdJqDtgYkfecGbuZFLneC6Nr8u6CYfXuUPog@mail.gmail.com

author
#9 lore raw
Quoted 7 lines · Kevin
Quoted 2 lines · Ross Boylan

My local master branch is the result of a merge of upstream master

and

Quoted 2 lines

some local changes. I want to merge in more recent upstream work. git pull doesn't seem to have updated origin/master, and git

Quoted 7 lines

checkout

Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 8 lines
Quoted 3 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.