On Wed, Feb 5, 2020 at 1:42 PM Paul Fertser <[email protected]> wrote:
> Hello, > > On Mon, Jan 20, 2020 at 12:36:55PM -0800, Tim Newsome wrote: > > I don't think there's an option to do that. But we can get a similar > effect by > > switching submit strategy from Cherry-Pick to Fast-forward Only. That > way the > > submitter must manually rebase changes in the same order as they will > end up > > in master. So in effect, the submit will only fast-forward master to a > commit > > that has previously been built. > > > > That will require every patch to be rebased before submitting, which > means that > > a maintainer can't select more than one patch at a time to merge. Given > that > > maintainers already seem to have very little time to review/merge > patches, I > > prefer the status quo. Breakage has been rare, and at least it makes it > possible > > for sometimes a bunch of patches are all merged together. > > We can change the submit strategy temporarily for big tree merges (as > when the strategy is _not_ cherry-pick hitting "Submit" on the last > change in the tree will get all the changes it depends on submitted > automatically) but in general I agree with Tim here, Cherry-Pick is > working good enough for the OpenOCD workflow and usecases, the > breakage is rare and short-living while usability advantages are high. > > For our use-case, I think Rebase Always would be a good fit. Basically just what we do today, except enforce relationships so we don't have to manually make sure we submit them in order which IMO is cumbersome. It wouldn't provide any additional build checks before updating master though. Also I think it requires a newer Gerrit. /Andreas
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
