git – setting a commit's parent without rebase

I used git-svn to create a git mirror of an SVN repository. The structure inside the SVN was a little off-standard, so git created a branch that has no common commit with the master branch.

      A---B---C topic

D---E---F---G master

I know that commit A is based off commit E and I’m pretty positive that I’ve fixed the issues causing git not to recognize that fact (using filter-branch). What I want to do is re-attach topic to the master branch, setting E as the parent of A:

  • GitHub issues - Reference a file in the repo
  • How can I get content of a file from git index?
  • How to automatically align/sync a forked Github origin/master branch to upstream/master?
  • Is it possible to fast forward another branch without checking it out?
  • How to see whats changed between last commit and now(after making some changes)
  • How to serve GIT through HTTP via NGINX with user/password?
  •       A---B---C topic
    D---E---F---G master

    git-rebase doesn’t seem to work for me because the diff for commit A lists the creation of a whole lot of files that already exist in master, resulting in a huge number of conflicts.
    From my understanding of git just setting E as the parent of A should be enough to solve all problems.
    Is this possible? If it is, how can I do it?

  • git: show all files changed between two commits
  • Why does git rebase --onto a b, git rebase --onto b a create a different SHA1 from the original?
  • How do I backport a commit in git?
  • What is the difference between git push.default=current and push.default=upstream?
  • Can I view instant results after a git push?
  • What's the Git approach to publish a patch queue?
  • 3 Solutions collect form web for “git – setting a commit's parent without rebase”

    Have a look at grafts (the graft file can be found in .git/info/grafts). The format is pretty simple:

    <commit sha1> <parent1 sha1> <parent2 sha1> … <parentN sha1>

    This makes git believe that a commit has different parents than it actually has. Use filter-branch to make grafts permanent (so the grafts file can be removed):

    git filter-branch --tag-name-filter cat -- --all

    Note that this rewrites history of the repository, so should not be used on shared repos!

    If you only want to rewrite the history of the commits that are being grafted onto the master branch, for example, use this command:

    git filter-branch --tag-name-filter cat -- master..

    Based on your diagrams (although I’m concerned about what you mean by “I’m pretty positive that I’ve fixed the issues causing git not to recognize that fact (using filter-branch).”), you should be able to do something like the following.

    # checkout A
    git checkout A
    # Reset the branch pointer to E so that E is the parent of the next commit
    # --soft ensures that the index stays the same
    git reset --soft E
    # Remake the commit with the E as the parent, re-using the old commit metadata
    git commit -C HEAD@{1}
    # Rebase the topic branch onto the modified A commit (current HEAD)
    git rebase --onto HEAD A topic

    All you need is this:

    git rebase --root --onto master^^ topic^^ topic

    the root option lets you include A.


    Add the --preserve-merges option if you want to retain the branching and merging of the part that you are rebasing.

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