How do you get git to always pull from a specific branch?

Question

I'm not a git master, but I have been working with it for some time now, with several different projects. In each project, I always git clone [repository] and from that point, can always git pull, so long as I don't have outstanding changes, of course.

Recently, I had to revert to a previous branch, and did so with git checkout 4f82a29. When I was again ready to pull, I found that I had to set my branch back to master. Now, I can not pull using a straight git pull but instead, have to specify git pull origin master, which is annoying, and indicates to me that I don't fully understand what is going on.

What has changed which does not allow me to do a straight git pull without specifying origin master, and how to I change it back?

UPDATE:

-bash-3.1$ cat config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[branch "master"]
[remote "origin"]
    url = [email protected]:user/project.git
    fetch = refs/heads/*:refs/remotes/origin/*

UPDATE 2: To be clear, I understand that my original method may have been incorrect, but I need to fix this repo so that I can simply use git pull again. Currently, git pull results in:

-bash-3.1$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either.  Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull  ').
See git-pull(1) for details on the refspec.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

    branch.master.remote = 
    branch.master.merge = 
    remote..url = 
    remote..fetch = 

See git-config(1) for details.

I can tell git pull which branch to merge, and it works correctly, but git pull does not work as it did originally before my git checkout.

Cramp

What does your .git/config look like? What did you do after you checked out that commit? – Acclivity

Did you do commits on top of 4f82a29? – Portage

Pat, I did not do any commits on top of it. This is on a server, and we needed to roll back to a stable version in order to hide a bug we had created. This system is not for development purposes, so I simply wanted to roll back, wait while we fixed the bug, and then pull back to the head version. – Cramp

Ryan, I've updated to include the .git/config. After the checkout, I didn't do anything. This computer is a server, not for development. – Cramp

Answer 1

Under [branch "master"], try adding the following to the repo's Git config file (.git/config):

[branch "master"]
    remote = origin
    merge = refs/heads/master

This tells Git 2 things:

1. When you're on the master branch, the default remote is origin.
2. When using git pull on the master branch, with no remote and branch specified, use the default remote (origin) and merge in the changes from the remote master branch.

I'm not sure why this setup would've been removed from your configuration, though. You may have to follow the suggestions that other people have posted, too, but this may work (or help at least).

If you don't want to edit the config file by hand, you can use the command-line tool instead:

$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

Danille

This worked for me as well, I had checked out a project from github. I'm running OS X 10.4 – Pulmonate

Thank you very much - this happened to me on a single developer project with one "server" repository and two computers (which I used to push/pull frequently with no issues before the glitch), don't know why, but the fix worked fine! – Fully

See answer by Head to avoid having to edit the config file by hand – Kappa

What do you mean by Under [branch "master"] – Decarbonate

@ianj: In the Git config file (from the repo root, .git/config). – Danille

@ianj: From the command line, you can always do $ git config branch.master.remote origin ; git config branch.master.merge refs/heads/master instead. – Danille

+1 from me. I've just installed git 1.7.4 and have been working through the excellent book 'Version Control with Git'. It seems that 1.7.4 doesn't seem to set the repository up the same way as the book suggests, something that other users have had problems with judging by the erratta on the book's web site. – Smail

I had this problem with a new branch and this worked for me, just had to add that branch and lines to my .git/config replacing master with my other branch's name! +1 – Rollerskate

@mipadi, your answer is absolutely correct, thanks a lot. Just FYI, I use git remote show origin to see if it is safe to use git pull or git push. If there is any problem, I will use git branch --set-upstream master origin/master to do the same thing as you said, but only no need to bother with refs/heads/master. I think a lot of people don't what does refs/heads/master mean. :) – Mithridate

Better to use git branch --set-upstream as referenced in one of the other answers. (I think this is fairly new though) – Afflatus

@ianj: If the file doesn't have a [branch "master"] line in it already, add that line, then add the subsequent lines in the answer. – Gigantean

added this one as global using --global flag after the config – Labaw

git config --global branch.main.remote origin && git config --global branch.main.merge refs/heads/main – Stage

Answer 2

If you prefer, you can set these options via the commmand line (instead of editing the config file) like so:

  $ git config branch.master.remote origin
  $ git config branch.master.merge refs/heads/master

Or, if you're like me, and want this to be the default across all of your projects, including those you might work on in the future, then add it as a global config setting:

  $ git config --global branch.master.remote origin
  $ git config --global branch.master.merge refs/heads/master

Amaurosis

+1 for knowing the magic word "refs/heads/master". I had no trouble figuring out how to set the variable, but had absolutely no clue what to set it to, and the man pages weren't much help. I eventually found the right place in the docs after I found this answer. For the curious: the magic word refers to a file path in .git in which git appears to keep the hash code of masters current commit. – Garth

Answer 3

git branch --set-upstream master origin/master

This will add the following info to your config file:

[branch "master"]
    remote = origin
    merge = refs/heads/master

If you have branch.autosetuprebase = always then it will also add:

    rebase = true

Conformity

I find this the easiest way to make git behave like asked, especially if there are more branches, not just remote (even if you have to do this for every branch, it's one time per branch) – Pelisse

I just tried this, and I get the error fatal: Not a valid object name: 'origin/master'. even though origin is a valid remote, and master exists, as per usual, in both repos. – Wharf

Ken, you need to do "git fetch origin" first to get the remote branch names. – Flews

Newer git wants you to use git branch --set-upstream-to=origin/master master. – Gemination

Answer 4

I find it hard to remember the exact git config or git branch arguments as in mipadi's and Casey's answers, so I use these 2 commands to add the upstream reference:

git pull origin master
git push -u origin master

This will add the same info to your .git/config, but I find it easier to remember.

Khasi

I agree. This should be the best simplest answer. – Berniecebernier

Your answer should include why it works and refer to the section in the docs that explains why. – Clamper

Answer 5

Git pull combines two actions -- fetching new commits from the remote repository in the tracked branches and then merging them into your current branch.

When you checked out a particular commit, you don't have a current branch, you only have HEAD pointing to the last commit you made. So git pull doesn't have all its parameters specified. That's why it didn't work.

Based on your updated info, what you're trying to do is revert your remote repo. If you know the commit that introduced the bug, the easiest way to handle this is with git revert which records a new commit which undoes the specified buggy commit:

$ git checkout master
$ git reflog            #to find the SHA1 of buggy commit, say  b12345
$ git revert b12345
$ git pull
$ git push

Since it's your server that you are wanting to change, I will assume that you don't need to rewrite history to hide the buggy commit.

If the bug was introduced in a merge commit, then this procedure will not work. See How-to-revert-a-faulty-merge.

Joo

You're giving me some great education here, which I appreciate, but I might not be describing my situation very well, so this isn't an exact match for my workflow. I'll probably post another question to address that. Thanks though, Paul! +1 to you, Sir. – Cramp

I just misread your situation. I'm glad you got the answer you needed. – Joo

Answer 6

There is also a way of configuring Git so, it always pulls and pushes the equivalent remote branch to the branch currently checked out to the working copy. It's called a tracking branch which git ready recommends setting by default.

For the next repository above the present working directory:

git config branch.autosetupmerge true

For all Git repositories, that are not configured otherwise:

git config --global branch.autosetupmerge true

Kind of magic, IMHO but this might help in cases where the specific branch is always the current branch.

When you have branch.autosetupmerge set to true and checkout a branch for the first time, Git will tell you about tracking the corresponding remote branch:

(master)$ git checkout gh-pages
Branch gh-pages set up to track remote branch gh-pages from origin.
Switched to a new branch 'gh-pages'

Git will then push to that corresponding branch automatically:

(gh-pages)$ git push
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1003 bytes, done.
Total 6 (delta 2), reused 0 (delta 0)
To [email protected]:bigben87/webbit.git
   1bf578c..268fb60  gh-pages -> gh-pages

Sciomachy

Thank you! This is exactly what I was looking for. I wonder why doesn't git automatically init with this option, as when you check out a new branch you want to track a remote with the same name 99% of the time – Inbreeding

Answer 7

Not wanting to edit my git config file I followed the info in @mipadi's post and used:

$ git pull origin master

Valiant

The point was to do this automatically rather than specifying it. – Encarnacion

Answer 8

Your immediate question of how to make it pull master, you need to do what it says. Specify the refspec to pull from in your branch config.

[branch "master"]
    merge = refs/heads/master

Acclivity

Shouldn't that be "refs/heads/master"? According to git-pull(1), this is the name of the branch at the remote site that is merged by default. – Patrimony

Yes, you're correct. The repo I took my example from is a special case. Corrected. – Acclivity

Answer 9

Just wanted to add some info that, we can check this info whether git pull automatically refers to any branch or not.

If you run the command, git remote show origin, (assuming origin as the short name for remote), git shows this info, whether any default reference exists for git pull or not.

Below is a sample output.(taken from git documentation).

$ git remote show origin
* remote origin
  Fetch URL: https://github.com/schacon/ticgit
  Push  URL: https://github.com/schacon/ticgit
  HEAD branch: master
  Remote branches:
    master                               tracked
    dev-branch                           tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Please note the part where it shows, Local branch configured for git pull.

In this case, git pull will refer to git pull origin master

Initially, if you have cloned the repository, using git clone, these things are automatically taken care of. But if you have added a remote manually using git remote add, these are missing from the git config. If that is the case, then the part where it shows "Local branch configured for 'git pull':", would be missing from the output of git remote show origin.

The next steps to follow if no configuration exists for git pull, have already been explained by other answers.

Kilogrammeter