On 12/06/2024 14:23, Mikael Morin via Gcc 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. > > 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. > >> >>> The number of merge points is a bit high (329) but I expected it to be a >>> manageable number. I tried again today with just the most recent merge >>> point, but it got stuck again. I should try with the oldest one, but >>> I'm afraid locking the repository again. >>> >>> I waited for the push to finish for say one hour before killing it >>> yesterday, and no more than 15 minutes today. Unfortunately, killing >>> the process doesn't seem to unlock things on the server side. >>> >>> It may be a misconfiguration on my side, but I have never had this >>> problem before. >>> >>> Sorry again. >>> >>> >
Perhaps you could create a mirror version of the repo and do some experiments locally on that to identify where the bottle-neck is coming from? R.
