FWIW, it's not hard to enforce fast-forward merges with a git hook; that way, we can guarantee that the history has no merge commits and is fully linear. GitLab has built-in support to enforce this for merge requests (though not for direct commits). I agree that linear history is a must for a project the size of WebKit. rNNNNNN tags would be nice, but hardly essential as long as the history is linear.

On Wed, Feb 20, 2019 at 1:38 PM, Bug Tracker <bug.tracking.acco...@protonmail.com> wrote:
I considered this option, but my work will involve touching multiple parts of the codebase and thus I would like to be able to keep up / merge locally with the upstream every now and then (e.g. on each relatively stable release, such as Apple's Safari Technology Preview).

However, all branches, tags etc. are available only on SVN.

Migrating to git would be wonderful, but a huge amount of infrastructure effort. Since it's unlikely that anyone is going to invest the large amount of effort required to transition WebKit to git anytime soon, I'd recommend learning how to work with git-svn. It's a bit of effort but not too hard, and way better than using Subversion directly.

Michael

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to