On Thu, May 11, 2023 at 10:05 PM Taylor Blau <me@xxxxxxxxxxxx> wrote: > On Thu, May 11, 2023 at 08:36:36PM -0500, Felipe Contreras wrote: > > Junio C Hamano wrote: > > > * ds/merge-tree-use-config (2023-05-10) 1 commit > > > (merged to 'next' on 2023-05-11 at e0dab53028) > > > + merge-tree: load default git config > > > > > > Allow git forges to disable replace-refs feature while running "git > > > merge-tree". > > > > > > Will merge to 'master'. > > > source: <pull.1530.git.1683745654800.gitgitgadget@xxxxxxxxx> > > > > Why was this series merged after only 11 minutes of review window? Are patches > > from GitHub favored over all others? > > Certainly not. > > The reason that this was merged quickly is because both of the first two > reviewers had already seen the patch and reviewed it earlier on the > git-security list. The patch that Stolee sent was urgent enough to merit > a quick merge. There's a quick review, and there is zero review. Even Derrick Stolee wanted more time for the public list to review the patch. If the eyeballs of the public list are not wanted after a security review, then why bother sending it here? Just merge it directly from git-security. I don't think that's desirable though. I share the opinion of Linus Torvalds that security fixes are not special: they are just another fix. Therefore they should go through the same process as any other patch, because just like any other patch, they can introduce regressions, and benefit from more eyeballs. If "given enough eyeballs, all bugs are shallow", I fail to see why we would want less eyeballs for security fixes. I for one found two issues with the patch, my first comment was a bit more than an hour later, and it's already merged. I don't think that's ideal. Cheers. -- Felipe Contreras
