65

I don't get the difference between git rebase origin and git rebase origin/master. In my case I cloned a git repository twice. In the first clone I have to use git rebase origin and in the other clone I must use git rebase origin/master.

An example: http://paste.dennis-boldt.de/2011/05/11/git-rebase

Dennis
  • 4,011
  • 7
  • 36
  • 50
  • Could you give more information about what you're doing? 'git rebase origin' shouldn't work because 'origin' is a remote not a branch (at least by default, you could name a branch origin.) – asm May 11 '11 at 11:43
  • I added an example to my question. Once I am able to use `git rebase origin` (line 27). At the other clone it doesn't work (line 54), so I have to use `git rebase origin/master` (line 57) – Dennis May 11 '11 at 12:23
  • 1
    Both forms use [gitrevisions](https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html) syntax to name a specific commit. As the man page notes, `origin` "means", in effect, "whichever `origin/*` branch is named by `origin/HEAD`". Most commonly, `origin/HEAD` names `origin/master` (this shows up in `git branch -r` output, as `origin/HEAD -> origin/master`). If `origin/HEAD` is *missing*, you just get an error (as @Dennis did). If you `git remote set-head` it (as in the accepted answer) you can choose how `origin/HEAD` resolves. – torek Mar 06 '17 at 04:57

3 Answers3

74

git rebase origin means "rebase from the tracking branch of origin", while git rebase origin/master means "rebase from the branch master of origin"

You must have a tracking branch in ~/Desktop/test, which means that git rebase origin knows which branch of origin to rebase with. If no tracking branch exists (in the case of ~/Desktop/fallstudie), git doesn't know which branch of origin it must take, and fails.

To fix this, you can make the branch track origin/master with:

git branch --set-upstream-to=origin/master

Or, if master isn't the currently checked-out branch:

git branch --set-upstream-to=origin/master master
CharlesB
  • 86,532
  • 28
  • 194
  • 218
  • Actually I found the one and only difference: `test` is having `remotes/origin/HEAD` additionally. So, you're correct. How can I add this to the clone `fallstudie`? http://paste.dennis-boldt.de/2011/05/11/git-branch – Dennis May 11 '11 at 13:08
  • `git branch --set-upstream master origin/master` – CharlesB May 11 '11 at 13:11
  • It's not the solution. The error is still `invalid upstream origin` and there is still just one origin branch. – Dennis May 11 '11 at 13:33
  • Can you post the result of `git branch -a` in `fallsudie`? – CharlesB May 11 '11 at 13:52
  • Actually I did the initial commit from `fallstudie` and `test` was a clone after the first commit. So the _pointer_ `remotes/origin/HEAD -> origin/master` which test is having is missed. Here is the result: http://paste.dennis-boldt.de/2011/05/11/git-branch-2 - Btw: I am using 1.7.5.1 – Dennis May 11 '11 at 13:57
  • A new clone is adding that pointer. I could delete the folder and clone it again to get the pointer. But that doesn't make me happy. – Dennis May 11 '11 at 14:06
  • What about `git config branch.master.remote origin`? – CharlesB May 11 '11 at 14:07
  • You can try to run `git remote show origin` to see what's the different between two clone. – winterTTr May 11 '11 at 14:23
  • Thx for the idea winter. But there is no difference, as you can see here: http://paste.dennis-boldt.de/2011/05/11/git-remote-show-origin – Dennis May 11 '11 at 14:36
  • The problem is just with the first clone of the new empty repository, from which I did the initial push. Here the steps to reproduce: http://paste.dennis-boldt.de/2011/05/11/git-new-repo-initial-push – Dennis May 11 '11 at 14:39
  • 1
    This answer is what worked to me. Thanks. Just updating it as --set-upstream is deprecated. Now the option is --track or --set-upstream-to – Shad Dec 24 '15 at 23:49
  • Also very important is, to `git fetch` before rebase from origin. – lennart Oct 19 '22 at 08:20
24

Here's a better option:

git remote set-head -a origin

From the documentation:

With -a, the remote is queried to determine its HEAD, then $GIT_DIR/remotes//HEAD is set to the same branch. e.g., if the remote HEAD is pointed at next, "git remote set-head origin -a" will set $GIT_DIR/refs/remotes/origin/HEAD to refs/remotes/origin/next. This will only work if refs/remotes/origin/next already exists; if not it must be fetched first.

This has actually been around quite a while (since v1.6.3); not sure how I missed it!

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • 3
    I never answered: I'm using that quite a lot now, and it is just working well! – Dennis Oct 12 '13 at 11:34
  • When I was attempting `git rebase origin`, I was seeing the error `invalid upstream origin`. Running this command fixed my problem. – DrStrangepork Nov 13 '14 at 18:39
3

You can make a new file under [.git\refs\remotes\origin] with name "HEAD" and put content "ref: refs/remotes/origin/master" to it. This should solve your problem.

It seems that clone from an empty repos will lead to this. Maybe the empty repos do not have HEAD because no commit object exist.

You can use the

git log --remotes --branches --oneline --decorate

to see the difference between each repository, while the "problem" one do not have "origin/HEAD"

Edit: Give a way using command line
You can also use git command line to do this, they have the same result

git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master

winterTTr
  • 1,739
  • 1
  • 10
  • 30
  • Correct, it seems like that. With that additional file I am getting the missed HEAD-branch. I did on my Linux system: `echo "ref: refs/remotes/origin/master" > .git/refs/remotes/origin/HEAD`. Thanks winter. – Dennis May 11 '11 at 15:17
  • 1
    @Dennis: The upshot here is that `origin` means `origin/HEAD`, but git is a little iffy about actually determining origin's HEAD. The remote protocols don't actually allow for transferring symbolic refs, so when you clone, it effectively asks the remote for the SHA1 of HEAD, and then figures out what ref also points to that commit. (If there are multiple, it picks master first.) And remote update and such don't actually touch remotes' HEADs, so you're stuck doing it manually if you didn't get it when you cloned. – Cascabel May 12 '11 at 03:22
  • @Jefromi: I realized that git is iffy. Thanks for your explanation. – Dennis May 12 '11 at 11:09