> On Feb 20, 2019, at 12:14 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > 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.
I think our concern is not just linearity. The reason Ryosuke suggests monotonically increasing revisions is because we often need to answer questions like the following: - This performance graph shows a regression between revision A and revision B, I wonder how many revisions are between those? - I need to manually bisect a regression between revisions X and Y. I wonder what the approximate midpoint is? Monotonically increasing sequential numbers make it super easy to answer questions like that. Ideally, such revision numbers would also be accepted by all tools we have to work with. Many git revision number solutions I have seen involve running an extra tool or consulting an additional website to be able to make determinations like this, and that would be a significant task on performance regression defense in particular. We’d love to hear about solutions that can provide something like this, ideally ones that are GitHub compatible. > > 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
