git rebase — unexpected mismatch of my hashes

Question

1) why wasn\'t i given an opportunity to stage pieces of my commits so i can tease them into distinct commits before merging with team? 2) why doesn\'t the hash before

Answer 1

You wrote in a comment:

what im saying is that the net result of the rebase in my OP was no change, so even though rebase (by definition) doesn't preserve commit history, it just so happens that the sha1 hash of the old head and the sha1 hash of the new head would be expected to be identical, despite being separate commits, because their text content is exactly the same

The hash of a commit is depending on:

1. the tree of this commit (i.e. the current state of your sources)
2. The hashes of any parents of the commit
3. the commit metadata (author date, author, commit date, committer, commit message, and similar.)

After your rebase the first one is the same, and maybe (I'm not sure) even the last one (at least, parts of it). But certainly the second one is not the same, and thus you get another commit-ID. This is a good thing, as it allows you to have at the same time the original and the new commit in your repository.