Created attachment 452446 [details] emerge --info portage Hello. I occasionally see the following problem during 'emerge --sync': >>> Syncing repository 'gentoo' into '/var/portage'... /usr/bin/git fetch origin --depth 1 remote: Counting objects: 16, done. remote: Compressing objects: 100% (6/6), done. remote: Total 16 (delta 12), reused 13 (delta 9), pack-reused 0 Unpacking objects: 100% (16/16), done. From https://github.com/gentoo-mirror/gentoo + 7a9417b...8483dac master -> origin/master (forced update) Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. error: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. === Sync completed for gentoo q: Updating ebuild cache in /var/portage ... q: Finished 39720 entries in 0.556075 seconds This happens almost every time git-gc automatically kicks in. I can easily fix the problem locally, but I hope it can be avoided at all. I usually don't manually touch that repo, only portage touches that. Of course I have to touch it manually to resolve the problem seen above, but that's it. My portage is master @ d075422a, but I've seen this problem with earlier revisions as well. Please fix.
Created attachment 452448 [details] /etc/portage/repos.conf/gentoo.conf
guess, that git fetch --depth=1 has to be reconsidered as gitcmd used by default during sync. doing shallow fetches each sync is a broken concept. it only needed for initial clone. using git pull is a way to go each sync and without --depth=1. originally, when this implemented, it served only for clone of repo, when it's not exist. there is no evident performance, bandwidth savings with this and instead lot of artifacts people have here and there.
I've posted a patch for review: https://archives.gentoo.org/gentoo-portage-dev/message/45274fce1b057fe65ea94d952e131605 https://github.com/gentoo/portage/pull/66
(In reply to Oleg from comment #2) > doing shallow fetches each sync is a broken concept. It might be feasible, but inideed it seems that git support is not good enough for it to be a practical default at this time.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=903c4b1a67689c4b8cc59113a56d58575cf7db8e commit 903c4b1a67689c4b8cc59113a56d58575cf7db8e Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-07-10 07:03:35 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-07-11 06:10:41 +0000 GitSync: support sync-depth (bug 552814) Support sync-depth for shallow sync, using git reset --merge just like in the earlier implementation that was reverted in commit ab840ac982d3c8b676b89f6bedd14e85dd06870f. Also, run git gc --auto in the foreground, in order to trigger periodic housekeeping and hopefully avoid errors from automatic git gc calls as reported in bug 599008. The default sync-depth is unlimited, which means that default behavior remains unchanged (unlike the previous implementation that was reverted). Bug: https://bugs.gentoo.org/552814 Bug: https://bugs.gentoo.org/599008 man/portage.5 | 3 ++- pym/portage/repository/config.py | 4 ---- pym/portage/sync/modules/git/git.py | 26 +++++++++++++++++++++++++- 3 files changed, 27 insertions(+), 6 deletions(-)
(In reply to Larry the Git Cow from comment #5) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/proj/portage.git/commit/ > ?id=903c4b1a67689c4b8cc59113a56d58575cf7db8e I've made it run the garbage collection in the foreground as follows, so that anything that really requires intervention should be immediately visible: git -c gc.autodetach=false gc --auto
