2

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 the rebase equal to the hash after the rebase? I see no messages indicating there was a squashed whitespace or something.

GIT [work]  git log --oneline -n10
7784ea8 dataloader populates with relatively sane data for masteritem and event; some component changes
1d9b3fe masterlist, promote draft, various commands, display tweaks on all components
76bea59 display strings
...
GIT [work]  git rebase -i team

edit first commit, squash next two commits

Stopped at 76bea59... display strings
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

PS [55] git status
# Not currently on any branch.
nothing to commit (working directory clean)
PS [56] git rebase --continue
[detached HEAD e373567] display strings
 49 files changed, 917 insertions(+), 460 deletions(-)
 delete mode 100644 source/...
 delete mode 100644 source/...
 delete mode 100644 source/...
 ...
Successfully rebased and updated refs/heads/work.
GIT [work]  git log --oneline -n10
e373567 display strings
bddc2fe unit test for object attrs, verify repeating in framework
548e1e9 sync with cvs; fixed test case compile error
Dustin Getz
  • 21,282
  • 15
  • 82
  • 131

3 Answers3

11

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.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
  • Why having the original and the new commit a good thing? Can you explain which use case takes advantage of this? I believe that a duplication in the repo is not a good thing. – mljrg Apr 30 '14 at 19:43
  • The original commit remains after the rebase? I do not see it if i use `git log`. Are you saying there is some way of accessing the original commits that existed before the rebase ? – faizal Aug 14 '14 at 17:15
  • 1
    @faizal the rebase creates new commits, which do not have the old commits as anchestors. `git log` shows only commits which are anchestors of the named commit (or current HEAD commit, if none), so they are not shown by default. – Paŭlo Ebermann Aug 19 '14 at 18:10
2

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."

Dustin Getz
  • 21,282
  • 15
  • 82
  • 131
Šimon Tóth
  • 35,456
  • 20
  • 106
  • 151
  • right, but in this case, rebase didn't actually do anything, so i expected the final hash to be equivalent since the content didn't change. any intermediate commits would obv have new hashes. – Dustin Getz Feb 28 '11 at 16:55
  • Well, that is how rebase works. You can use `rebase --onto` if you want to rebase just part of the branch. Although I'm pretty sure that `--onto` doesn't work with interactive. – Šimon Tóth Feb 28 '11 at 16:58
  • 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 – Dustin Getz Feb 28 '11 at 17:11
  • 3
    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. – araqnid Feb 28 '11 at 18:02
  • I could not reproduce rebase changing commits hash ids (or at which circumstances), therefore I suspect rather in my case I could have used cherry pick, which regenerates hash ids by its definition - https://stackoverflow.com/questions/20698118/is-cherry-pick-command-generate-the-different-hashcode-of-same-commit/20698167#20698167 – FantomX1 Oct 15 '21 at 11:28
0

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

Dustin Getz
  • 21,282
  • 15
  • 82
  • 131