[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Moving to Git
From:       Maciej Stachowiak <mjs () apple ! com>
Date:       2019-02-20 21:08:13
Message-ID: EFDB3FCE-9701-4499-8C1A-7A70D426BCBC () apple ! com
[Download RAW message or body]



> On Feb 20, 2019, at 12:14 PM, Michael Catanzaro <mcatanzaro@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.account@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


[prev in list] [next in list] [prev in thread] [next in thread]