i've done that when i forgot to add some necessary files in the initial initial commit. since the adding the forgotten files did not include any changes warranting a different message, it lets me know i was a knucklehead and the commits are meant be considered the same commit. it's much faster than looking up to see if there's a way to amend an existing commit with additional files, and then going through the process of actually doing it. my use of git is add/commit/push/clone/switch/fetch. after that, it's 100% look it up and hope i'm not going to bork my repo by following some SO thread
For what it's worth, you can still do it with those commands, though I understand part of the point is that you don't necessarily remember all of the options for them. But in this case, it should be simple:
Unlike amend, you can target an older commit rather than just the very-most-recent (great if you're separating the rename/refactor from the rewrite) and you can delay the second step of actually changing history until you're sure stuff is in a good state.
This is particularly useful for the review process: All the changes during the review process can be "fixup" commits, allowing reviewers to easily see what did (or didn't) change since their last interaction. At the same time, all the fiddly fixes and back-and-forth stuff won't be in the final history, only a smaller number of "real" commits that future maintainers would care about.
