I am making a bash script to update if a ebuild if the repository from which the ebuild's source was from has updated, I simply wish to diff git.eclass with the following: --- /usr/portage/eclass/git.eclass 2006-09-11 01:46:09.000000000 -0700 +++ git.eclass 2006-10-20 21:37:16.482600856 -0700 @@ -204,6 +204,7 @@ ${EGIT_UPDATE_CMD} ${EGIT_OPTIONS} origin ${EGIT_BRANCH}:${EGIT_BRANCH} \ || die "${EGIT}: can't update from ${EGIT_REPO_URI}." + EGIT_BRANCH=$(git rev-parse ${EGIT_BRANCH}) ${EGIT_DIFFSTAT_CMD} ${oldsha1}..${EGIT_BRANCH} fi This will produce much more helpful output in the environment, and will do the same exact thing it's always done in the eclass. Before: EGIT_BRANCH=master (default) After: EGIT_BRANCH=a12e57fe4b6db23c4c7f8a6095692e4ce633bb72 (or whatever the head is at the time) To go into more detail, this is needed due to those who use a shared distfiles directory, if one computer updates, the other will never know if the ebuild in question has been updated. Thank you.
Created attachment 100117 [details, diff] git-show-hash.patch from comment 1
I don't like the idea of showing something other than the branch name when we're advertising that it is the branch name. However, I'd be fine with displaying that as the head of that branch in a separate line.
OK, in that case, I'll tell you what I need and hopefully you can figure the best way of doing this :) I need the actual hash of the installed version (after the update). I also need it to be accessible from the /var/db/pkg/*/environment.bz2. This is the case I was trying to make above, substituting EGIT_BRANCH's name for it's hash after the update. Again, Thanks
I'd agree to add something like this if it was 'standard' across all of the scm.eclass'es. Maybe you should open a RFC thread in gentoo-dev. - ferdy
I'm not sure about a standard, but svn does have something like this: ESVN_WC_REVISION, which was all I was looking for in git. Anyhow, nevermind, I think I've found another way to skin the cat. Thanks for your time.
@Avuton: Is there anything I can do wrt this bug ? or should I close it ? - ferdy
No, I actually worked around this limitation, thanks for the help (I didn't know which resolution to close it with, so I didn't touch that)
Since you don't need it anymore, I'd say it is RESOLVED->INVALID. Cheers. - ferdy
