Am Samstag, den 06.06.2020, 08:57 +0100 schrieb Kevin Barry: > The fast-forward rebase has two advantages that I can think of: > - the git history is cleaner/easier to parse > - it prevents the situation that sometimes arises where a couple of > patches - that pass testing independently, but will break when > combined - from making it into master (and breaking it)
This can be avoided by using merge trains which tests the simulated merge(s) in order of their queue position: https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ (We're not using this yet because it only makes sense with proper merges, not with rebase + fast-forward.) > If we move to merge commits our git history will mostly have a merge as > every other log entry. It's a small loss, but a tolerable one in my > opinion. I don't know how people feel about the second issue. The > staging branch existed in the past to stop such breaks making it into > master. Maybe it's OK since our source of truth is still on Savannah? I > don't have strong opinions about it. The mirroring is automatic, so everything that hits master on GitLab is pushed to Savannah within 1-5 minutes. > Is it a crazy idea to consider some automatic way of doing the rebase + > merge on all branches in Patch::push state? I believe Gitlab allows for > scheduled pipeline execution. (I'm just throwing the idea out there.) I also mentioned the idea of a custom queue implementation initially. However, I'd go a slightly different way: - Have a Patch::merging label that the author can assign *after* the patch was in Patch::push. - Use some form of automation (webhook, cron?) that picks the "next" merge request with Patch::merging and issues API calls to rebase and merge. The tricky part is the automation which needs a very robust design: It must neither miss when to act nor act if there's a merge running that it maybe didn't trigger itself. If somebody wants to do a prototype implementation, I'm willing to give feedback and maybe help getting it to the finish-line. For now, I personally prefer going back to "real" development on LilyPond. I think there's a lot more to be done with higher benefit. Jonas > > Kevin > > > > > > I’m not knowledgeable enough to discuss the benefits and downsides of > > > merge commits vs fast-foward rebase, so I’ll leave it to others. But > > > I think you make a valid point in that our current linear > > > mandatory-rebase strategy is cumbersome, heavy on the CI pipelines and > > > generating a lot of noise. > > > > I would like to comment on the last two points: > > * "heavy on the CI pipelines": The number of pipelines wouldn't change > > with merge commits. We still get one pipeline per push and we would > > want to get testing before a set of changes hits master. This is the > > same as we have right now. > > * "generating a lot of noise": The only "noise" is the rebase > > operation before merging. Everything else will stay the same: review > > comments, discussion, notifications about pushes, etc. > > NB: I don't see a need to rebase during review. If you chose to do it > > anyway, the same "noise" applies after switching to merge commits. > > > > The only advantage of merge commits that I agree with is GitLab's > > ability to queue merges and perform them automatically. That may > > qualify as less "cumbersome", but lowering the expectation that every > > merge request in Patch::push must be merged on the same day will get us > > the same result, without any change. > > > > > That being said, that’s only one of the three issues I raised in my > > > latest message (the other two being: how we’ll be handling Issue pages > > > from now on, and how patch reviewing can be made a bit more lenient > > > and smoother). > > > > Please see my replies from last Saturday which went unanswered AFAICT. > > > > Jonas > > > > > > > Jonas has started updating the CG, but that’s bound to reach a > > > roadblock if the underlying policies are not discussed and agreed upon > > > first. > > > > > > Cheers, > > > -- V. > >
signature.asc
Description: This is a digitally signed message part
