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

Note that before Git 2.29 (Q4 2020), Git could also change the hash of the commit onto which you are rebasing in the todo message, commit which should not change (since you are replaying old commits onto this one).

See commit 5da69c0 (13 Aug 2020) by Antti Keränen (Detegr).
^{(Merged by Junio C Hamano -- gitster -- in commit 4499a42, 19 Aug 2020)}

rebase -i: fix possibly wrong onto hash in todo

^{Found-by: Jussi Keränen
Signed-off-by: Antti Keränen
Acked-by: Alban Gruin}

'todo_list_write_to_file' may overwrite the static buffer, originating from 'find_unique_abbrev', that was used to store the short commit hash 'c' for "# Rebase a..b onto c" message in the todo editor.

This is because the buffer that is returned from 'find_unique_abbrev' is valid until 4 more calls to find_unique_abbrev are made.

As 'todo_list_write_to_file' calls 'find_unique_abbrev' for each rebased commit, the hash for 'c' is overwritten if there are 4 or more commits in the rebase.
This behavior has been broken since its introduction.

Fix by storing the short onto commit hash in a different buffer that remains valid, before calling 'todo_list_write_to_file'.