Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork a

Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork and ask the maintainer to pull it). Gerrit actively encourages you to rebase and rewrite (and lose) your development history in the pursuit of a "perfect" one-hot non-merge history patchset, which actively loses information about the context of where your changes where applied. The problem with submitting a rebased branch is that while there are no apparent merge conflict and your changes appear to have been developed on the tip of master, your changes may actually have been developed on a much older version of master. Builds may appear to compile fine but they might not make sense - when you discard and rebase the context of commits, you lose important information.