"git rebase origin" vs."git rebase origin/master"

Question

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

Solution 1

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

Solution 2

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!

Solution 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

Comments

[Dennis]

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? paste.dennis-boldt.de/2011/05/11/git-branch

[CharlesB]

git branch --set-upstream master origin/master

[Dennis]

It's not the solution. The error is still invalid upstream origin and there is still just one origin branch.

[CharlesB]

Can you post the result of git branch -a in fallsudie?

[Dennis]

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: paste.dennis-boldt.de/2011/05/11/git-branch-2 - Btw: I am using 1.7.5.1

[Dennis]

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.

[CharlesB]

What about git config branch.master.remote origin?

[winterTTr]

You can try to run git remote show origin to see what's the different between two clone.

[Dennis]

Thx for the idea winter. But there is no difference, as you can see here: paste.dennis-boldt.de/2011/05/11/git-remote-show-origin

[Dennis]

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: paste.dennis-boldt.de/2011/05/11/git-new-repo-initial-push

[Dennis]

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.

[Cascabel]

@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.

[Dennis]

@Jefromi: I realized that git is iffy. Thanks for your explanation.

[Dennis]

I never answered: I'm using that quite a lot now, and it is just working well!

[DrStrangepork]

When I was attempting git rebase origin, I was seeing the error invalid upstream origin. Running this command fixed my problem.

[Shad]

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