On Wed, 12 Jun 2024 at 14:23, Mikael Morin <morin-mik...@orange.fr> wrote: > > Le 12/06/2024 à 14:58, Jonathan Wakely a écrit : > > On Wed, 12 Jun 2024 at 13:57, Mikael Morin via Gcc <gcc@gcc.gnu.org> wrote: > >> > >> Le 12/06/2024 à 13:48, Jakub Jelinek a écrit : > >>> Hi! > >>> > >>> Yesterday the gcc git repository was locked for 3 hours > >>> locked by user mikael at 2024-06-11 13:27:44.301067 (pid = 974167) > >>> 78:06 python hooks/update.py > >>> refs/users/mikael/tags/fortran-dev_merges/r10-1545 > >>> 0000000000000000000000000000000000000000 > >>> c2f9fe1d8111b9671bf0aa8362446516fd942f1d > >>> process until overseers killed it but today we have the same > >>> situation for 3 ours and counting again: > >>> locked by user mikael at 2024-06-12 08:35:48.137564 (pid = 2219652) > >>> 78:06 python hooks/update.py refs/users/mikael/tags/toto > >>> 0000000000000000000000000000000000000000 > >>> cca005166dba2cefeb51afac3ea629b3972acea3 > >>> > >>> It is possible we have some bug in the git hook scripts, but it would > >>> be helpful trying to understand what exactly you're trying to commit > >>> and why nobody else (at least to my knowledge) has similarly stuck > >>> commits. > >>> > >>> The effect is that nobody can push anything else to gcc git repo > >>> for hours. > >>> > >>> Jakub > >>> > >> Yes, sorry for the inconvenience. > >> I tried pushing a series of tags labeling merge points between the > >> fortran-dev branch and recent years master. > > > > Just pushing tags should not cause a problem, assuming all the commits > > being tagged already exist. What exactly are you pushing? > > > Well, the individual commits to be merged do exist, but the merge points > don't and they are what I'm trying to push.
I see. Merge commits are still commits, so they get processed by the hooks. We don't even allow merge commits on trunk or the release branches, so I don't know how the hooks handle them. > To be clear, the branch hasn't seen any update for years, and I'm trying > to reapply what happened on trunk since, in a step-wise manner. With > 300 merges I'm summing up 60000 commits of history. Yes, that's going to give the hooks a ton of work to do. So it's probably just the number of commits being pushed to the branch, not the fact they're merge commits (and certainly not the tags referring to any of those commits, which should be very cheap). If it was my branch, I'd be tempted to rebase the fortran_dev branch on trunk, instead of merging years and years of trunk commits into the ancient branch. Or create a new branch, say "fortran_dev_2", from trunk, then merge the fortran_dev branch into that, and push the new branch. That would presumably be a much smaller set of "new" commits relative to trunk, so much less work for the hooks.
