I'm running a whole slew (100+) live ebuilds, mostly kde-live-branch (4.x.49.9999) by numbers, which I don't follow /that/ closely, but a handful of which I follow quite closely indeed. These include openrc and netifrc, pan, btrfs-progs, and at times various xorg/mesa/x-driver related packages. (Additionally, I run a git kernel, but I handle that with my own scripts separate from portage.) For the live-git packages I follow closely, I have developed a routine, helped by a bunch of scripts. Generally after I've started the tree syncs and have checked the overlay changelogs using git whatchanged in them, I switch to checking the live-git packages in another terminal window. My routine then consists of: 1) ebuild <pkg> unpack ... to git-pull the latest updates. 2) (again, automated via script) cd to the local git repo and run git whatchanged <various options> ORIG_HEAD.. 3) Review the whatchanged log, looking for anything that might be interesting. 4) For any commit that looks interesting in the whatchanged log, (via script) cd to the local git repo and run git show <options> <commit> 5) After I'm finished informing myself about what has changed and getting a preview of the effect it might have on my installation, I run ebuild <pkg> clean. 6) If there were indeed changes, I'll often emerge the package separately, handling any etc-updates and other desired changes individually for these focus packages. 7) All live packages are rebuilt (again, for the ones I've already built, individually) with an emerge @live-rebuild. As I said, these close-focus live-git packages include openrc, which recently switched to git-r3.eclass. Unfortunately, I can no longer figure out how to do steps 2-4. I did figure out that I needed to set EGIT_NOSHALLOW and set it. The shallow file in the git repo no longer appears, so that seems to be working. But cd-ing to the either the local repo or the working checkout and trying to run the usual git whatchanged or git show commands instead gives me an error. =:^( In the local repo it errors out with something about HEAD, which is reasonable, since I checked and the usual FETCHHEAD and HEAD files don't exist. And the checkout into PORTAGE_TMPDIR that with git2.eclass contained a .git subdir so git commands could be run there as well... .git is missing in the checkout with git-r3.eclass. So /that/ doesn't give me anything but the no git repo found error when I try to run a git command there. So how on earth am I supposed to get my usual git whatchanged and git show output? And if I want to run other git commands, perhaps checking out tags instead of head... BTW, seems the fetch is run with --notags, so I don't even GET the tags! Eek! WTF did you do with my previously working git-based ebuilds? As of now I think there are openrc changes, but I can't see what they are, and without that, I don't want to try upgrading "blind". (Being able to have the detail of the git logs is the big reason I switched to openrc-9999 in the first place.) And with netifrc being so recently part of openrc, I don't want to try updating it until I can update openrc, too. And since @live-rebuild would update openrc along with the hundred-plus kde-branch ebuilds, I can't update any of them either, all because I can't get to my openrc git whatchanged logs!
The eclass uses two branches: ${CATEGORY}/${PN}/${SLOT}/__main__ for the current commit, and: ${CATEGORY}/${PN}/${SLOT}/__old__ for the previous state. The first is updated during fetch, and during the checkout eclass compares both for diffstat and updates __old__ to match __main__. One thing you could theoretically do is running fetch without checkout, and then you'd have two nicely disjoint branches. However, this will require some special magic until EAPI 6, and I don't think you can do it yourself right now. The other thing is a bit more work but since you have a script already: git branch ${CATEGORY}/${PN}/${SLOT}/__my_old__ \ ${CATEGORY}/${PN}/${SLOT}/__old__ # unpack like usual git whatchanged \ ${CATEGORY}/${PN}/${SLOT}/__my_old__..${CATEGORY}/${PN}/${SLOT}/__main__ In other words, you fork the branch so that the eclass doesn't break it for you and use that afterwards. Alternatively, you could just get commit hash before the update and pass that to whatchanged. I haven't tested it but it should work. I think you can handle it from this point. If you have any further questions, feel free to ask.
Thanks for the hints. For now I punted. If it's a git-r3 based ebuild, for whatchanged I set --branches=${CATEGORY}/${PN}/${SLOT} and it works just like git2 did (I normally just select/paste in the range displayed in the fetch). For show I check to see if there's anything passed on the commandline. If not I feed it ${CATEGORY}/${PN}/${SLOT}/__main__, thus defaulting to branch-tip as normal. I might have to tweak things a bit as more packages switch to git-r3, and EAPI6 may well trigger further tweaks, but that's nothing unusual; I've tweaked and further developed the script over time as I needed to and will continue to do so. But I still think git-r3 needs a simpler way to work with the local git repo. It's a LOT less direct and intuitive than git2 is/was in that regard, for sure! I came real close to setting ${PN}_LIVE_REPO to point to portage-independent locally maintained and separately script-pulled git repo. Perhaps I'll still ultimately go that route, as I could script those pulls from my main sync script, then, just as I do the emerge-fetch-world from the sync script. Then I'd have full control over the primary local repos regardless of what the eclass did, but I guess it'd mean dupped repos then, with independent and portage-controlled versions for each package.
It's not 'local git repo'. It's local store that is entirely for internal use of the eclass.
