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
