And if you do know what the parent is then how is it different from a "PR"?

The difference is that Gerrit tracks the evolution of, and reviews, each individual commit.

With a PR, you lose history when rebasing and all commits have to be approved as a whole.

What does it mean for an individual commit to evolve? I think of commits as being the atoms of the evolutionary process; i.e. evolution is a sequence of commits.

> With a PR, you lose history when rebasing

I don't quite understand that point. (I know what rebasing is.)

> and all commits have to be approved as a whole.

Hm, so why would one want to approve an individual "commit"? In my world a commit should be a meaningful change but isn't necessarily self-contained and hence not approvable. This sounds like what you're calling commits are in fact independent / self-contained and deployable units of change. So then

> A PR is roughly the same as a stack of Gerrit CLs.

Does a "CL" contain one or more than one of the entities you refer to as "commits"above?

Isn't it the other way around? A Gerrit thing is a stack of mini "PR"s, where each "PR" is a small, but independent / self-contained and deployable, unit of work. In any case, a PR contains many non-self-contained units (commits) so I'm having a hard time equating a PR and a stack of CLs.