2

I need to rebase my git repo from a different repo. And not add the different repo as a subtree. The different repo has changes to the same files I'm working on in my local repo. (Don't ask why we don't just unite the repos into different branches in one repo [politics].)

My repo and the common repo respectively.

a-b-c-d

a-b-c-w-x-y-z

My repo needs to become

a-b-c-w-x-y-z-d

Remember it's a different repo not just a different branch. The strategy I was pursuing was to add a branch to my repo from the common repo via these command

remote add common-repo ssh:/path/to/common/repo

Then I see the common repo in my "git remote -v" command. But I don't see it in my "git branch -v" command. If I could just get that into a branch, do the rebase/merge, then remove the branch or never push the branch, then I be rebasing my repo from that common repo.

Of course I want my own repo to retain all the history that the common repo had, noit a collapsed merge.

Joe C
  • 2,728
  • 4
  • 30
  • 38

3 Answers3

3

I assume there's a common parent, since you used some letters twice, I think you can achieve that by adding the second repo as a different remote

git remote add second_origin URL

then fetch the second remote

git fetch second_origin

then do the rebase

#assuming you are on origin/master
git rebase second_origin/master master

I'm not sure this will work, but for me it seems logically correct, and keep in mind if the whole rebase goes crazy and you find your self stuck, you can always run git rebase --abort

Mohammad AbuShady
  • 40,884
  • 11
  • 78
  • 89
1

To see remote branches, you should use one of this:

git branch -a
git branch -r

instead of 

git branch -v

Once you can see, for example, branch remotes/origin/master, then, to rebase your master branch on top of that you should just do:

git checkout master
git rebase origin/master
elmart
  • 2,324
  • 15
  • 17
  • This didn't work. It was a: fatal: Needed a single revision invalid upstream remotes/jb-ia/internal Also I'd rather be able to pull the remote branch locally then merge it from that local branch, in case I need to mess with it a little locally to make the merge easier. – Joe C Nov 26 '13 at 19:02
  • You always merge/rebase involving only local branches. There's no other way to do it. ;-) When we talk about remote branches, we mean local branches reflecting the state of remote branches (what are called remote tracking branches). In any case, your problem is due to the remote/ prefix in the command. My fault. Not needed there. Editing my answer to reflect this. – elmart Nov 26 '13 at 19:12
  • From what I see in the error message, in your case it would be: git rebase jb-ia/internal – elmart Nov 26 '13 at 19:13
0

I'm assuming that commits a, b and c are the same but not identical. In this case you just fetch from the other repo

git fetch otherrepo

then you rebase your work onto the last common part, c

git rebase --onto otherrepo/c ^myrepo/d myrepo/d

since it's one commit, in this case a cherry-pick would do

git checkout otherrepo/c
git cherry-pick myrepo/d

Substitute the repo/commit markers with branches you create to represent them. The above will be easier to deal with that way.

If you are going to work with this other repo in this manner, I would suggest you merge and turn on rerere as you will never be able to publish your merges and the merges on your side will get more and more complicated. Rerere will allow you to do this fast as any conflict resolutions will be remembered in the future.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141