Right now, Portage doesn't store commit number when installing packages in the git version, and there is no simple and 100% accurate way to get the commit [1]. Portage stores only package version (nines), which is pretty much useless: > 1682775580: >>> emerge (38 of 64) net-p2p/transgui-9999 to / > 1682775580: === (38 of 64) Cleaning (net-p2p/transgui-9999::/var/db/repos/lekto/net-p2p/transgui/transgui-9999.ebuild) > 1682775580: === (38 of 64) Compiling/Merging (net-p2p/transgui-9999::/var/db/repos/lekto/net-p2p/transgui/transgui-9999.ebuild) > 1682775603: === (38 of 64) Merging (net-p2p/transgui-9999::/var/db/repos/lekto/net-p2p/transgui/transgui-9999.ebuild) > 1682775605: >>> AUTOCLEAN: net-p2p/transgui:0 > 1682775605: === Unmerging... (net-p2p/transgui-9999) > 1682775606: >>> unmerge success: net-p2p/transgui-9999 > 1682775607: === (38 of 64) Post-Build Cleaning (net-p2p/transgui-9999::/var/db/repos/lekto/net-p2p/transgui/transgui-9999.ebuild) > 1682775607: ::: completed emerge (38 of 64) net-p2p/transgui-9999 to / Enhancement: keep git commit in emerge.log. [1] https://forums.gentoo.org/viewtopic-p-8834024.html#8834024
Given the way this is implemented via eclass, I don't think adding the commit hash to emerge.log is possible or even makes sense. You can find the commit hash in the environment file under /var/db/pkg.
The problem is when the package was working, but after the update, it stopped. Or when I checked last time x updates, x month ago it was working but now it won't. If it shouldn’t be stored in emerge.log, maybe it makes more sense to store it in /var/cache/distfiles/git3-src? It could be something simple, like a text file containing information about when and what was updated to which commit.
I wonder what mechanism smart-live-rebuild uses. Ideally we'd have a standard mechanism defined in PMS which is what bug 482666 is about.
(In reply to Zac Medico from comment #3) > I wonder what mechanism smart-live-rebuild uses. Ideally we'd have a > standard mechanism defined in PMS which is what bug 482666 is about. smart-live-rebuild checks whether EGIT_COMMIT in /var/db/pkg matches the output of git-ls-remote(1), i.e. it does network lookups at dependency calculation time. It seems to have similar ad-hoc mechanisms for other VCS types. It's possible to record the update history of a local git repo in the reflog, but it needs to be explicitly opted-into in bare repositories (config core.logAllRefUpdates). It adds a few tens of KiB to a repo's size and would've helped in this case, so I'd like to propose having git-r3.eclass flip that setting on unless there's a good reason not to.
