On 2014-12-30 10:32:22 -0600 (-0600), Dolph Mathews wrote: > The default behavior, rebasing automatically, is the sane default > to avoid having developers run into unexpected merge conflicts on > new patch submissions.
Please show me an example of this in the wild. I suspect a lot of reviewers are placing blame on this without due investigation. > But if git-review can check to see if a review already exists in > gerrit *before* doing the local rebase, I'd be in favor of it > skipping the rebase by default if the review already exists. > Require developers to rebase existing patches manually. (This is > my way of saying I can't think of a good answer to your question.) It already requires contributors to take manual action--it will not automatically rebase and then push that without additional steps. > While we're on the topic, it's also worth noting that --no-rebase > becomes critically important when a patch in the review sequence > has already been approved, because the entire series will be > rebased, potentially pulling patches out of the gate, clearing the > Workflow+1 bit, and resetting the gate (probably unnecessarily). A > tweak to the default behavior would help avoid this scenario. The only thing -R is going to accomplish is people uploading changes which can never pass because they're merge-conflicting with the target branch. -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
