I did git rebase --interactive b222222, but it didn’t show the commit with the sha b222222. Why is that?
A shortened version of my git log reads like this:
commit c333333
commit b222222
commit a111111
I tried to do git rebase -i b222222 and I saw this:
pick c333333
# Rebase b222222..c333333 onto b222222 (1 command)
b222222 is the one I want to edit. Why do I only see c333333 listed, not b222222?
Note on potential duplicate[1]
[1]: I’m sure there’s a question out there like this one, I just couldn’t find it. These are just a few questions I found that didn’t help me:
- Why git rebase doesn’t show commits I want to squash?
- using git rebase -i
- Certain commits not showing up during git rebase -i
- Git rebase: finding the “next” commit to be rebased?
The most useful hint I found was in a low-point unaccepted answer about changing an old commit message, and it wasn’t as useful as it could be.
Since it was so hard to find, even if there is a duplicate question and answer out there, this post might still be useful. There have been a few conversations in stackoveflow meta about deliberately posting duplicates in order to help guide people to useful answers. Feel free to give a link and mark it as a duplicate, of course.
tl;dr: When rebasing, you specify what you don’t want to rebase. In other words, you specify the new “base” (commit or branch), which represents everything you don’t want to change.
This means the title has a false premise:
git rebase -i doesn’t show the sha of the commit I asked to rebase
The commit you listed is not what you “asked to rebase”, but is instead what you asked your new base to become, which is what you do not wish to rebase. (Or perhaps a slightly better word choice would be “replay” or “reapply”.)
At first this seems counter intuitive, but when you rebase onto branches it makes more sense. For example, suppose you have my-feature currently checked out and you want to update your branch with the latest version of main. You could use the following commands:
git fetch
git rebase origin/main
Note this is equivalent to the slightly less efficient, yet likely more common, set of commands:
git switch main
git pull
git switch my-feature
git rebase main
Also, note that:
git switch my-feature
git rebase main
is the same thing as the one-liner:
git rebase main my-feature
The second argument, my-feature, is only necessary if you don’t have it checked out already.
For completeness, this is actually short for the fuller syntax of rebase:
git rebase main my-feature --onto main
In words, you can read this as:
Take all of the commits reachable by
my-feature, that aren’t reachable bymain, and replay them one by one, in order, ontomain.
Another way to say that is:
Take all the commits on
my-feature, minus all the commits onmain, and replay them one by one, in order, ontomain.
So now substituting your example:
git rebase --interactive b222222
is, in the expanded syntax equivalent to:
git rebase -i b222222 c333333 --onto b222222
In words that says,
Take all commits reachable by
c333333(which is all three commits), minus all commits reachable byb222222(the bottom two commits), and note this leaves just the top 1 commitc333333, and take that one commit and replay it ontob222222, and do so in interactive mode so that I can view what the rebase will do, and possibly edit it.
This is the reason you must specify the parent of the first commit you wish to rebase- it’s because you’re specifying all of the commits to exclude. IMHO this is one of reasons rebase is initially confusing and oftentimes a difficult concept to learn. I hope by the time you read this sentence it will be less so. 😉
4
This is expected git behavior. From this answer to a different question:
[In]
git rebase -i <commit_sha>,<commit_sha>is the SHA one commit before the commit to be changed
If you want to edit b222222, you should use the sha before b222222 – commit a111111. You don’t need to go searching for a111111 in your git log, though, you can just do the following:
git rebase -i b222222~1
You should then see this in your interactive rebase:
pick c333333
pick b222222
The ~1 means the commit before the given commit. You usually see it with HEAD~, but it can work with any commit sha.