Git rebase

[DrCoffee84]

I'm reporting an issue with the following solution:
solutions/squashing_commits.md

mkdir git
cd git
git init 
echo > "Mario" > file 
git add file 
git commit -m "1. New file"
echo -n " & Luigi" >> file
git add file 
git commit -m "2. Added Luigi" 

git log

output:

git log
commit b8c90c65bc1f5dfd68eb6f5f9cb9ce5ec133faa1 (HEAD -> master)
Author: Daniel Boullon <[email protected]>
Date:   Tue Feb 4 02:15:45 2025 -0300

    2. Added Luigi

commit 09801b54880b3d3c762abcd7712a49e693b601ee
Author: Daniel Boullon <[email protected]>
Date:   Tue Feb 4 02:15:44 2025 -0300

    1. New file

Error:

git rebase -i HEAD~2
fatal: invalid upstream 'HEAD~2'

If i do HEAD~1 i see only 1 commit:

git rebase -i HEAD~1
pick b8c90c6 2. Added Luigi

# Rebase 09801b5..b8c90c6 onto 09801b5 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#         create a merge commit using the original merge commit's
#         message (or the oneline, if no original merge commit was
#         specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#                       to this position in the new commits. The <ref> is
#                       updated at the end of the rebase
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.

It looks like git rebase -i HEAD~2 fails with fatal: invalid upstream HEAD~2 , while git rebase -i HEAD~1 only shows one commit.
This happens because HEAD~2 refers to a commit that does not exist in the current history depth. The first commit (1. New file) is actually the root commit of the repository, and Git does not allow rebasing onto a non-existent parent. In other words, since there is no second parent before HEAD, HEAD~2 is invalid. To modify both commits, you can use git rebase -i --root, which allows rewriting the root commit as well.

$ git rebase -i --root
[detached HEAD 00ebfd0] 1. New file 
 Date: Tue Feb 4 02:15:44 2025 -0300
 1 file changed, 2 insertions(+)    
 create mode 100644 file
Successfully rebased and updated refs/heads/master.

$ git log
commit 00ebfd0bf0c6dca9e3198e6de54846d88c255ed3 (HEAD -> master)
Author: Daniel Boullon <[email protected]>
Date:   Tue Feb 4 02:15:44 2025 -0300

    1. New file

    2. Added Luigi

Maybe you should clarify this in the solution or start with an initial commit, then rebase the next two without using --root. This would help avoid confusion for people who are learning.