Git rebase commit selection

I have a git tree that looks like the following:

enter image description here

  • Git cherry pick vs rebase
  • How does git deal with binary files?
  • checkout remote branch in git
  • Squashing Commits to a single commit for a bitbucket pull request
  • Large files extension for git
  • How can I get/list/see all the descendants of a commit with git (or gitk)?
  • Because of the review tool we use, we cherry pick changes in rather than merging them. This leaves us with some logical duplicates, whose branch I then just delete. For example, the change one below ssl_tests “Modification: Changing name…” can also be seen in dev.

    Now, perhaps this is a lack of understanding on my part of cherry pick, but those commits have different hashes and so are different commits right? Even though they are logically the same.

    However, when I go to rebase ssl_tests onto dev, git manages to figure out that those cherry picked commits are upstream and then only rebases the “New Feature: Unit tests…” commit from ssl_tests.

    As per usual, with git, this is great! This is exactly what I want! My question though, is how does git figure out that it doesn’t need to rebase the other commits if they have different hashes?


  • git push renames branch
  • gerrit and apache2 config issue
  • Moving a file to different folder along with history in git
  • How do I update a git submodule without checking it out
  • can't push with gitolite - ENV GL_RC not set
  • How to use multiline commit messages with github?
  • One Solution collect form web for “Git rebase commit selection”

    Git is looking at more than just the SHA1 here. It’s actually considering the contents of the commit. It sees that the trees resulting from applying the commit and not applying the commit are the same; that is, the commit would be empty if applied to the new base. Thus, rebase is smart enough to know that it needn’t bother including those commits.

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