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

so i figured out why the rebase didn't give me an opportunity to edit -- what i wanted to do right after git rebase -i team was git reset HEAD^1; git add -p to tease appart my big commits into smaller chunks.

http://git-scm.com/docs/git-rebase

Answer 2

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.

Answer 3

Rebase creates completely new commits (that means new commit IDs). That's why you shouldn't use rebase on anything that is publicly available since your rebase will break everyone's else repositories.

From a comment... "the commit ID is a hash of the state of the commit and the commit metadata, including the parent IDs. as soon as you change any metadata in a commit, all its descendants are affected. In the case you describe, I'd expect your old and new heads to have the same tree ID, since they represent no content change, but still different commit IDs since the commit graph has changed."