Git rebase commit selection

I have a git tree that looks like the following:

enter image description here

  • git says “The following untracked working tree files would be overwritten by checkout” when switching branches
  • How to interface PHP and Git repository
  • Git merge compare from to meaning
  • Is there a “correct” way to sync databases between live and dev servers?
  • In Eclipse/EGit is there a way to edit commit message of unpushed/local commit?
  • Discover which methods and classes were modified in a git commit?
  • 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?


  • TeamCity getting stuck at “Updating sources” on one Git repo
  • git-filter-branch: leave directory structure
  • Problems with merging after a git update-index --assume-unchanged
  • How to “git show” a merge commit with combined diff output even when every changed file agrees with one of the parents?
  • Git: How to keep local feature branch updated with changes made in dev?
  • Can I get the path of a .bbappend file?
  • 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.