You got it right. There is a separate set of tooling layered on top of the VCS, which maintains a sub-history of each commit. The tool (Gerrit, Phabricator, etc.) tracks this relationship between commits, and whatever is eventually merged into the repo.

This architecture assigns each line of code a nested history: the public commit log, and also the sub-history of each commit, which evolved during code review.

IMO it would be better if the code review changes were manifest in the public commit log (e.g. via feature branches), instead of being tracked separately. The code review layers add duplicative complexity.