[webkit-dev] WebKit Transition to Git

Maciej Stachowiak mjs at apple.com
Tue Oct 13 12:32:20 PDT 2020

> On Oct 2, 2020, at 10:59 AM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:
> On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand <philn at igalia.com> wrote:
>> Would you also consider preventing merge commits in order to keep a
>> clean mainline branch?
> Big +1 to blocking merge commits. Merge commits in a huge project like WebKit would make commit archaeology very frustrating. (I assume this is implied by the monotonic commit identifiers proposal, but it doesn't exactly say that.)

I’m assuming your objection is to regular merges, but how do you feel about squash merges? Or do you think all PRs should be landed by rebasing?

My own preference would be to require squash merge, because it keeps the history simple for the main branch, but does not risk putting intermediate revisions which may work or even build on the main branch.

 - Maciej

> I'm sure transition to git and GitHub should go well. I would have selected GitLab myself -- it's nicer and also overwhelmingly popular -- but whatever. (Does GitHub have merge request approvals? Replicating our reviewer/owner permissions with GitLab merge request approvals would be easy.)
> One downside is that using github.com might actually make it *too* easy to spam us with low-quality issue reports and merge requests. We've historically been pretty bad at maintaining a clean issue tracker -- the quantity of untriaged issues on Bugzilla is very high -- and GitHub will make this worse. That's not an issue with the GitHub platform, though. Just something to stay on top of.
> Michael
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list