3 ms·

Note that those points are particular disadvantages of the email workflow - all of these things are solved in modern tools like Gerrit.

• da39a3ee 6y ago
  If you don't know what the parent is in Gerrit then how can you run CI on the patch? And if you do know what the parent is then how is it different from a "PR"?
  • lima 6y ago
    A PR is roughly the same as a stack of Gerrit CLs. 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.
    • da39a3ee 6y ago
      > The difference is that Gerrit tracks the evolution of, and reviews, each individual commit. 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.