Re: jk/tag-contains: stalled

[Jeff King <peff@peff.net>]

On Thu, Aug 05, 2010 at 03:18:15PM -0400, Jay Soffian wrote:

> On Thu, Aug 5, 2010 at 3:06 PM, Jeff King <peff@peff.net> wrote:
> > I agree it's a pretty generic name. I was trying to make this as generic
> > as possible, at least within the domain of commits, so it could be a
> > faster replacement for calls to is_descendant_of. Maybe commit_contains?
> 
> I'm going to side-track this slightly. I wonder why branch and tag
> have --contains, but it is not more generically available via
> rev-list?  I needed it the other day and spent 5 minutes looking at
> what it would take before I ended up just calling merge-base in a loop
> for the commits I wanted to check.

I'm not sure rev-list makes the most sense. We already have "show
commits in X, but not in Y". But I gather you wanted "from a list
(U,V,W,X), print each that contains Y". Which is not really a rev-list
function anymore, as it is not about listing revisions, but rather about
grepping a list you've given it.

Something like "git for-each-ref --contains" seems more sensible to me,
though it is not as generic as we could make it (I cannot use an
arbitrary list of commits to the "haystack", but only ones that have
refs pointing to them).

-Peff