Right now the general policy is that we don't allow unmasked (hard or via keywords) ebuilds in the tree if they use an scm to fetch their sources. There are a bunch of reasons for this, and for the most part they make sense.
I was wondering if this policy still made sense in the case of scm ebuilds that pull a particular git commit. While portage can't check the Manifest, the fact is that git will in this case, and since we're pointed at a content-hashed commit we can ensure that the package never changes. We of course can't mirror it with the current setup (there is no real reason we couldn't mirror git, but this is a different problem). Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed to think of any actual QA issues. That is, something that would make our tree inconsistent, or create a security vulnerability. Am I just not thinking of something? It would probably be most useful for packages that track a backport branch or something along those lines - where upstream does not regularly update their tarballs so we're constant creating patchsets. In this case all we'd have to do is bump the commit ID in the ebuild. -- Rich
