[webkit-dev] WebKit Transition to Git

[Adrian Perez de Castro]

Hi,

On Tue, 06 Oct 2020 03:42:11 +0300 Konstantin Tokarev <annulen at yandex.ru> wrote:
 
> 05.10.2020, 13:26, "Frédéric Wang" <fwang at igalia.com>:
> > One thing to take into account is that WebKit's repository is big and
> > public GitHub/GitLab prevent creating large repository by default. This
> > means it might not be possible for contributors to actually fork
> > WebKit's repository on their account and then create a pull request
> > (which is the standard way IIUC).
> 
> Every repository which is already present on GitHub can be forked by
> anyone without any restrictions.
> 
> There are restrictions for repositories which are not forks, e.g. if you
> create new repo on your account and try to push whole WebKit there,
> you'll get an error.
> 
> > Instead, we would probably end up
> > doing like web-platform-tests and give contributors the permission to
> > create branches to the WebKit account and make Pull Request to the
> > master branch. 
> 
> This is not needed and should be avoided - private development branches
> in main repo will confuse users and will be copied into all forks.
 
While I agree that having private development branches in the main repository
can be confusing for people not used to that, OTOH it is awkward to have to
“fork” [1] the repository to one's user area, then add an extra remote to
one's local clone of the upstream (main) repository, just to be able to submit
a “pull request” [2].

Also with Git{Hub,Lab} it's an annoyance that one has to go through the web
interface to create a “pull request”. Being able to do “webkit-patch upload”
saves a non negligible amount of developer time. It is even better with
Gerrit: do “git push” directly to a remote ref and a changeset will be
automatically created for review [3].

> >Probably, we should forbid people to commit to the master
> > branch directly (I think someone broke WPT's master branch that way last
> > year)...
> 
> I have to admit that ability to make small unreviewed commit for thing like 
> typo fix or change in personal watchlist is rather useful...

I suppose this could be solved by still making a “pull request” and tagging
it with some label to be merged automatically by some bot. It won't be as
fast as directly landing a patch, but on the upside all patches (including
unreviewed ones) would be landed in the same way.

As a side note, Gerrit can be configured to allow direct pushes that bypass
the review process.

Cheers,
—Adrián

---
[1] I put “fork” in between quotes because it's a perversion of the term: what
    it does is create a clone of the repository in Git{Hub,Lab}'s own servers
	which happens to be accessible remotely with one's credentials.
[2] GitHub's usage of the “pull request” term is yet another perversion: Git
    has had a pull requests (produced by a command) long before GitHub even
	existed, see https://git-scm.com/docs/git-request-pull
[3] https://gerrit-documentation.storage.googleapis.com/Documentation/3.2.3/intro-user.html#upload-change
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201008/23e0ba55/attachment.bin>