190

I have a branch of a public repository and I am trying to update my branch with the current commits from the original repository:

$ git fetch <remote>
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 20 (delta 12), reused 0 (delta 0)
Unpacking objects: 100% (20/20), done.
From git://github.com/path_to/repo
  9b70165..22127d0  master     -> $/master
$ git rebase <remote>
fatal: Needed a single revision
invalid upstream <remote>

The <remote> is in place of my remote name and is not actually my remote name. The documentation on this error seems to be a bit loose.

Chris Martin
  • 30,334
  • 10
  • 78
  • 137
jrlmx2
  • 1,967
  • 2
  • 11
  • 9
  • 2
    I got this error for an unrelated reason - using "git rebase --interactive c4e9c94^" from a Windows command prompt. It prompted me "More?", and regardless of how it answered the prompt, it said "fatal: needed a single revision". But when I ran the same command from bash, it worked fine. – Richard Beier Sep 23 '12 at 02:07
  • As a side note, for me in addition to having upstream branch listed with "remote" I had to fetch the specific branch that I wanted to rebase on. "git fetch master". Fetching just with "git fetch " still would give me this error. – Sweetness May 12 '17 at 15:25

8 Answers8

163

You need to provide the name of a branch (or other commit identifier), not the name of a remote to git rebase.

E.g.:

git rebase origin/master

not:

git rebase origin

Note, although origin should resolve to the the ref origin/HEAD when used as an argument where a commit reference is required, it seems that not every repository gains such a reference so it may not (and in your case doesn't) work. It pays to be explicit.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • 2
    The latter should actually work - `origin` in ref context is interpreted as `origin/HEAD`. I've seen repositories end up not knowing what `origin/HEAD` is, though... – Cascabel Jan 25 '11 at 20:15
  • 1
    @Jefromi: I afraid that I don't believe you, I've just tried `git rebase origin` on a test repository (where `origin` has a `HEAD`) and I get the OP's error. The documentation for rebase doesn't say that a remote name is valid for the ``. – CB Bailey Jan 25 '11 at 20:21
  • 1
    @Charles: Well, it may be a bug? `git rev-parse origin` works, as does `git rebase origin` in my git.git clone (in up-to-date, fast-forward, and true rebase case, including interactive). – Cascabel Jan 25 '11 at 21:37
  • @Jefromi: Can you `git describe` your `HEAD`? – CB Bailey Jan 25 '11 at 21:40
  • @Charles: up to date, v1.7.4-rc3! I'm not terribly eager to do a bisect looking for this one... – Cascabel Jan 25 '11 at 21:41
  • Hm, and the [relevant documentation](http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html#_specifying_revisions) (third bullet) looks like it was added in October 2006, so it seems like it always should've worked. – Cascabel Jan 25 '11 at 21:48
  • @Jefromi: Are you sure you don't have a ref or branch called origin? I've tried with v1.7.4-rc3 and I still get exactly the same error message. – CB Bailey Jan 25 '11 at 21:48
  • I definitely don't. `find .git -name origin` produces the refs and reflog directories, and the packed refs don't have one either. I tried this in test repos, too - couple test commits, just enough to get the three basic rebase cases, and it works fine there too. I do think your answer is pretty definitely correct; you and James just appear to be having a similar issue. – Cascabel Jan 25 '11 at 21:54
  • Hmm, I don't have `refs/remotes/origin/HEAD`, but isn't the default ref spec for remotes: `refs/heads/*:refs/remotes/origin/*` which shouldn't keep a copy of `refs/HEAD` ? – CB Bailey Jan 25 '11 at 22:00
  • That's a great point - it looks like it's not generally fetched. It definitely has to be inspected when you clone, to determine your initial HEAD. I can deduce by removing and modifying it that subsequent fetches/remote updates don't refresh it. `git remote show origin` does attempt to show the remote's HEAD, though in my tests, whenever I check out a new branch in origin, it ends up thinking remote HEAD is ambiguous... it looks like this isn't terribly robust, whatever it is. Here's a script demonstrating that it works initially: http://pastebin.com/0ucBvqzm – Cascabel Jan 25 '11 at 22:15
  • @Jefromi: Perhaps the initial `HEAD` is fetched automagically in newer clones, my git clone that I tested with is quite old. – CB Bailey Jan 25 '11 at 22:18
  • Aha, and here's [the question](http://stackoverflow.com/questions/1614565/preview-changes-on-bare-repo-doesnt-work-correctly) where I learned that this *should* work. (see Jakub's comment.) I have since then been using `git log ..origin` quite a lot! – Cascabel Jan 25 '11 at 22:18
33

Check that you spelled the branch name correctly. I was rebasing a story branch (i.e. branch_name) and forgot the story part. (i.e. story/branch_name) and then git spit this error at me which didn't make much sense in this context.

ChrisJF
  • 6,822
  • 4
  • 36
  • 41
  • Exactly this. Typed `featureName` when the branch is actually named `features/featureName` – pkamb May 08 '16 at 06:36
  • 5
    Also a good idea to look for simple typos more thoroughly. I accidentally swapped two letters when creating branch and this typo was really hard to spot. – Olga May 23 '16 at 15:25
30

I ran into fatal: Needed a single revision and realized I didn't fetch the upstream before trying to rebase. All I needed was to git fetch upstream first.

Mario Olivio Flores
  • 2,395
  • 1
  • 20
  • 19
11

The issue is that you branched off a branch off of.... where you are trying to rebase to. You can't rebase to a branch that does not contain the commit your current branch was originally created on.

I got this when I first rebased a local branch X to a pushed one Y, then tried to rebase a branch (first created on X) to the pushed one Y.

Solved for me by rebasing to X.

I have no problem rebasing to remote branches (potentially not even checked out), provided my current branch stems from an ancestor of that branch.

Maitreya
  • 1,237
  • 11
  • 13
  • 3
    You can rebase to such a branch with `--onto`. Everything descends from *some* common ancestor (for normal repositories), so that isn't the problem. I've gotten this error from trying to rebase onto `foo` when I had not yet created the branch to track `origin/foo`. – cdunn2001 Nov 21 '11 at 16:46
1

The error occurs when your repository does not have the default branch set for the remote. You can use the git remote set-head command to modify the default branch, and thus be able to use the remote name instead of a specified branch in that remote.

To query the remote (in this case origin) for its HEAD (typically master), and set that as the default branch:

$ git remote set-head origin --auto

If you want to use a different default remote branch locally, you can specify that branch:

$ git remote set-head origin new-default

Once the default branch is set, you can use just the remote name in git rebase <remote> and any other commands instead of explicit <remote>/<branch>.

Behind the scenes, this command updates the reference in .git/refs/remotes/origin/HEAD.

$ cat .git/refs/remotes/origin/HEAD 
ref: refs/remotes/origin/master

See the git-remote man page for further details.

Jani
  • 853
  • 8
  • 20
  • @VladimirShefer rewrote the entire answer to use `git remote set-head` instead of messing with `.git/refs/remotes/origin/HEAD` directly. – Jani Feb 04 '21 at 11:31
  • Also, I think this answers the original question better than the accepted answer, which is just a workaround to the root cause. – Jani Feb 04 '21 at 11:32
  • thank you for you answer. It is much better now! I have deleted my downvote mark. – Vladimir Shefer Mar 15 '21 at 11:03
1

For me, to specify branch helps.

  1 [submodule "test/gtest"]
  2     path = test/gtest
  3     url = ssh://git@git.github.com/google/googletest.git
  4     branch = main
MeadowMuffins
  • 507
  • 1
  • 5
  • 20
0

git submodule deinit --all -f worked for me.

0

$ git rebase upstream/master

fatal: Needed a single revision

invalid upstream usptream/master**

So I tried $ git rebase remotes/upstream/master and it works for me.