On Mon, May 31, 2021 at 7:53 PM Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote: > > On 31/05/21 14.38, Chris Packham wrote: > >> Is your problematic repo public? If so, we can test against that. > >> > > > > Unfortunately not. It's actually an internal kernel tree which has a > > different root to upstream (hence using git replace to attach upstream). > > All of which make the history a bit funky. > > > > I don't know if the problem will survive anonymisation but I can try. > > > > Did you mean vendor kernel tree based on Linux kernel? Kind of. A repo that was created in 2007 before we were using git properly by extracting the kernel tarballs and adding our code. So although it's a kernel tree it shares no common history with Linus' tree. git fast-export/fast-import doesn't seem to like the affected repo so I'm not having much luck with making anything publicly available. > I think you can > try reproducing the issue with either Linus' tree [1] (mainline only) or > Greg's stable tree [2] (mainline + release branches and tags). > > [1]: https://github.com/torvalds/linux > [2]: https://github.com/gregkh/linux > I've tried a few experiments - cloning the "bad" repo -> no problem seen in clone - cloning the "bad" repo with --mirror -> no problem seen in clone - copying the "bad" repo -> same problem seen in copy So now that I have a copy that shows the problem I can do a few more things. - copy repo, remove replace refs (git replace -l | xargs git replace -d) -> problem remains - copy repo, remove replace refs and all remotes except origin -> problem remains - copy repo, run git gc -> no problem So the git gc seems to have done the trick. I'm happy enough to leave it there and hope that this thread is useful for future mailing list searchers. I'll keep a copy of the affected repo around if there is anything someone wants me to try.
