On Tue, Jul 05 2022, 程洋 wrote: > - git version: > 2.36.1 > - steps to reproduce the bug > : We have no idea actually. We're maintainer of our internal > git/gerrit. We found sometimes some user will invoke 100+ threads to > clone the same repository. And when we ask those guy, they say they > only executed the "git fetch" once. And just like the youtube videio, > you will find git fork a child git, and then grandson child git, and > loop like this forever until the server down. > If we copy their local repository to our own PC, and then execute `git fetch`, we can also reproduce it. It seems that some broken local git files cause this bug > - what you expect and actual behavior, as well as the differences > Mentioned above > - system info > Ubuntu 18.04 > - miscellaneous I assume you can't share the repo, but perhaps try if you can reproduce it with a "git fast-export --anonymize" version of it, and if so whether you'd be willing to share that. It will publish the "shape of the history" of the repo, but not any meaningful data (all commits, trees, blobs etc. are replaced). Alternatively myself & probably some other regular contributors to git would be willing to look at that repo + reproduction recipe off the public ML, to see if we could reproduce the issue, if that sounds good to you contact me off-list. Or perhaps we can still figure out a reproduction for this... The YouTube video shows that you're using various options to git-fetch, including filters, refspecs etc. Does a plain "git fetch" reproduce this, and if not what's the option (try adding them one at a time & experiment) that needs to be added to trigger this? I somewhat suspect some --filter funny business, but that's just a hunch...
