Summary: | reduced manifests w/ git | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Caleb Cushing <xenoterracide> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | CC: | alexxy, hollow, ikelos, jlec, robbat2, zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Caleb Cushing
2009-03-05 22:47:00 UTC
As an FYI, this has been discussed on the gentoo-scm ML. You should join and contribute there as well, obviously you have experience with it ;) Plz check the archives first before bringing up any old topics. that's been pointed out previously. I reviewed the archive and am on the list although it doesn't seem get much traffic (or something is wrong with my subscription) I'm not aware that a conclusion has been made. (In reply to comment #0) > # hash of 'Makefile' in the most recent commit on the current branch > $ git rev-parse HEAD:Makefile > 27b9569746179e68c635bdaab8e57395f63faf01 It will be useful to have a shared library for this (with python bindings), since it's relatively expensive to spawn a process like that. Having quick access to the digests (as the manifest currently provides) will allow quick validation of new metadata cache entries which will contain digests as described here: http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml Without quick access to ebuild digests, in order to validate metadata cache we'll have to compute ebuild digests during dependency calculations and that will hurt performance. Of interest might be dulwich [1] and gitpython [2] (there are ebuilds for both in my overlay). Both are pure-python git libraries (although it's not clear exactly how much each implements). Still, they're a starting point... 5:) [1] https://launchpad.net/dulwich [2] http://pypi.python.org/pypi/GitPython/ Everybody here, can we please continue this discussion explicitly on the -scm mailing list? We're trying to keep everything together in one please, so that anybody wanting to review the progress doesn't need to follow much in the way of links. zmedico: access to the Git index is certainly possible without the exec. What isn't avoidable in any case is checking that the ebuilds haven't changed (which git does via lstat for the most part). For the short-term however, I had thought I noted on the -scm mailing list that you can list the entire (or any subset) tree's SHA1 ids with a single exec() call using 'git ls-files --stage'. Adding '-d -m -o -k -t -v' is useful as it shows you potentially changed items as well, and '-u' beyond that is only the changed files. *** This bug has been marked as a duplicate of bug 333691 *** |