git add remote tracking branch to bare repo

1. I have a bare repo that was cloned from git.drupal.org.
2. I have cloned from this bare repo to various different websites.
3. From each of these, I push a site-specific branch onto the bare repo.

E.g. if I have foo.org and bar.org, then my bare repo has drupal's branches + one called foo and one called bar.

The idea was that I could make the most of git's hard links to save disk space with local clones. I thought I would keep the bare repo fetching from git.drupal.org, and pull changes down to my local copies, foo & bar. Then when an update came along it would be easy.

bare-repo$ git fetch >/dev/null ; git branch -a
* 7.x
  foo
  bar
  remotes/origin/7.x
  remotes/origin/8.x

foo and bar started out on branch 7.x but I'd like to update them to 7.8, e.g. by git rebase 7.8 but开发者_C百科 this fails:

fatal: Needed a single revision
invalid upstream 7.8

foo and bar cannot 'see' the bare repo's remotes. What can I do?

---

2 points, as explained in "git rebase fatal: Needed a single revision":

• you need to specify the name of a branch, which in your case would be origin/7.8, not 7.8:

   git rebase origin/7.8

should work.

• You can't rebase to a branch that does not contain the commit your current branch was originally created on. (so make sure that it is the case for your repo)

---

The OP artfulrobot reports:

git rebase origin/7.8 
fatal: Needed a single revision invalid upstream origin/7.8

To which I replied:

if 7.8 isn't present in origin as a branch, this error message is expected.
Maybe 7.8 is a tag in the 'origin' repo.
In this case, you need to explicitly fetch said tags first:

git fetch --tags origin

Then the rebase should work

---

you need a working folder for rebase. So you need to clone this repo and then do what you need. After that, push the modified branches back to the bare repo.

Alternatively, you can specify a working directory git --work-tree=../somedir rebase 7.8. Unfortunately the worktree and git dir options for the git command are not fully implemented for all commands. The first option is the best.

Rebase needs a working dir because it needs to give you control when it encounters a conflict. You can then fix the conflict and issue a git rebase --continue command to let it apply the rest of the commits on the new base.

Hope this helps.