This might be a silly semantics question but I'm asking anyway in case I'm not looking at this from the right perspective.
Let's say I have a simple repository with a master and feature branch - feature has a single commit, after which a commit for a Hotfix was added to master:
* 8aa11d5 (HEAD -> master) Hotfix
| * 73f496e (feature) Feature Added
|/
* d9588fc Initial File
I then rebase "feature onto master" by performing "git rebase master feature", which results in the following:
* aeaafd0 (feature) Feature Added, 'rebased onto master'
* 8aa11d5 (HEAD -> master) Hotfix
* d9588fc Initial File
At this point the only branch that has changed is feature, since I've incorporated the hotfix commit from master into it. Why then is this operation called "rebasing onto master" in the git docs and in online articles? Your immediate response may be "it's because when you then merge feature into master the commit chain will appear as if the feature commits were grafted onto master". I agree with that, which results in the following:
* aeaafd0 (HEAD -> master, feature) Feature Added, 'rebased onto master'
* 8aa11d5 Hotfix
* d9588fc Initial File
However, at the point in time I performed the rebase this wasn't true. The rebase certainly created a commit that links to the master tip, such that if I merge the two branches (fast-foward merge) then yes, I've rebased + merged onto master. In other words, the terminology of "rebasing onto master" implies a future operation that hasn't already happened.
Is this terminology used because it's assumed a merge will always logically follow the rebase? Or is it because I'm looking at this the wrong way?