Is there a merge strategy that just doesn't allow commit chains longer than 1?
Also https://gerrit-review.googlesource.com/Documentation/project-configuration.html says "When cherry picking a change, Gerrit automatically appends onto the end of the commit message a short summary of the change’s approvals, and a URL link back to the change on the web. The committer header is also set to the submitter, while the author header retains the original patch set author." I love that short message. It's useful to be able to easily see the code review comments and reviewer names. On Mon, Dec 11, 2017 at 11:43 AM, Tim Armstrong <[email protected]> wrote: > We recently had a bad merge that was allowed by the cherry-pick merge > strategy merging a simple without its ancestor (since they didn't change > any nearby lines): > https://lists.apache.org/thread.html/ee81ee3e396a9a7b1214d92d713a2d > 28f2f1f7058184504ebc399170@%3Cdev.impala.apache.org%3E > > It looks like the "rebase always" merge strategy avoids this by always > trying to rebase and merge the whole chain of commits. Does anyone have any > objections or thoughts about switching to this strategy? >
