How do I join two git repos without a common root, where all modified files are the same?

I have a git-cpan-init of a repo which yielded a different root node from another already established git repo I found on github C:A:S:DBI. I’ve developed quite a bit on my repo, and I’d like to merge or replay my edits on a fork of the more authoritative repository. Does anyone know how to do this? I think it is safe to assume none of the file-contents of the modified files are different — the code base hasn’t been since Nov 08′.

For clarity the git hub repo is the authoritative one. My local repo is the one I want to go up to git hub shown as a real git fork.

  • Git: Efficient steps to create a new branch and push to remote
  • Git - push to a remote-tracking branch in the remote repository
  • GIT clone repo across local file system in windows
  • In git, is there a simple way of introducing an unrelated branch to a repository?
  • git commit comment per file
  • Local branches with Bazaar?
  • Package management in git for windows?
  • I am trying to deploy my first django app on heroku and getting error a pre-receive hook declined
  • editing git patch gives “Your edited hunk does not apply”
  • git add remote branch
  • Show all stashes in git log
  • GIT: Any way to set default login credentials?
  • 2 Solutions collect form web for “How do I join two git repos without a common root, where all modified files are the same?”

    You should be able to add a remote to your existing repository (using git remote add) so that you can fetch the contents of the github repository into your existing repository.

    Assuming that you have a commit in your history (call it O) and a commit in the remote branch (call it R) that correspond to the same set of files (e.g. they are both imports of the same release version), then you can just do an ‘onto’ rebase. Assuming you have the tip of your changes currently checked out:

    git rebase --onto R O             # R and O are sha1 ids (possibly abbreviated)
    

    This replays all of your commits since O onto the new R root commit.

    Once you’ve done this, if you are not up to date with the latest remote master branch you can use a normal rebase to get there and git’s history tracking will take care that your changes are applied in a way that makes sense.

    git rebase <remote_name>/master   # where <remote_name> is whatever
                                      # you called the github remote when
                                      # you used git remote add
    

    A Graft Point would help I think.

    Git Baby is a git and github fan, let's start git clone.