git rebase implementation details

I am trying to figure out the working mechanism of git-rebase. Documentation provides information about what git-rebase does, but doesn’t comment on how it does?

I have looked into the source code, worked out some test cases and so far understand following:
1. Git maintains the state of rebase in .git/rebase-apply (with files like patch, final-commit, head-name etc)
2. Git uses git-format-patch to create all necessary patch files (which are inside rebase-apply)
3. Git uses git-am to apply those patches one by one

  • git pull request: resolve a merge conflict properly?
  • automatically removing conflict markers
  • TFS 2013 in VS reports no history for a file with multiple commits in Git
  • RoR/Heroku : detected sqlite3 gem which is not supported on heroku
  • How to Git fetch a remote repository and anchor it to a specified commit?
  • How to configure git repository so a branch other than master is checked out after a cloning?
  • I think I am missing quite a lot of details. Where can I find the implementation details? Is it simply dumping the patch and naively applying it?

  • xCode 4.5 git merge fails to commit or give errors
  • How can I pull git submodule automatically?
  • git clone --bare does not include branch master
  • git diff from heroku
  • How do you fetch a remote branch without “checking it out”
  • Best practice for tracking upstream in fork on github
  • One Solution collect form web for “git rebase implementation details”

    Your summary is basically complete. Rebase is actually relatively simple.

    1. First, the work to do is calculated. This is basically git rev-list <upstream>..<branch> to identify all the commits that need to be moved over.
      1. If you are doing a normal (patch-based) rebase, then the patches for each of those commits will be generated and saved in the rebase state folder (.git/rebase-apply).
      2. If you invoked rebase with git rebase --merge then the commits are stored in a different state folder (.git/rebase-merge).
    2. Next, the HEAD is detached and set to the onto commit (the new base branch, where you will be applying those changes).
    3. Application takes place until a commit cannot be applied.
      1. If you are doing a patch-based rebase, then patches are applied in order. If a patch fails to apply, then Git will try to instead cherry-pick the commit in question. This is because cherry-pick is able to write merge conflicts to the index and working directory.
      2. If you are doing a merge-based rebase, then the commit is cherry-picked.
    4. If a cherry-pick fails with conflicts, rebase stops and you (the user) must resolve any conflicts and git add them to the index. When you have resolved all conflicts, you can git rebase --continue.
    5. Once all conflicts have been applied, the original branch is updated to point to the final, rebased commit.
    Git Baby is a git and github fan, let's start git clone.