git rebase -i — why is it changing commit hashes?

Question

So I\'m more or less familiar with how rebasing works, but up until recently I usually just did a git rebase -i HEAD~20, and modified whatever needed to be modified

Answer 1

this will modify the hashes of all 20 commits, even if the only action I take is to squash the last two.

If by "the last two" you mean the most recent two commits in the history, then no, it won't.

Please be concrete, show the actual evidence you're looking at, the todo list you got and the one you executed. Characterizations are far too unreliablevulnerable to unshared context.

Here for instance is what happens when I squash the last two commits, as I understand it:

$ git log --oneline --reverse @{u}..
00f53a2 echo >master6
afcef3e echo >master7
1f55c48 echo >master8
c3197a0 echo >master9
d30bb35 (HEAD -> master) echo >master10
$ GIT_SEQUENCE_EDITOR='sed -i 5s/pick/squash/' git rebase -i
[detached HEAD 16dc80d] echo >master9
 Date: Mon Feb 5 09:25:55 2018 -0800
 2 files changed, 2 insertions(+)
 create mode 100644 master10
 create mode 100644 master9
Successfully rebased and updated refs/heads/master.
$ git log --oneline --reverse @{u}..
00f53a2 echo >master6
afcef3e echo >master7
1f55c48 echo >master8
16dc80d (HEAD -> master) echo >master9
$ 

you can see that the last two commits have been squashed together, the id's of all the commits whose history hasn't changed are left untouched.