Re: jk/tag-contains: stalled

From: Jeff King <peff@peff.net>
Date: Aug 5, 2010, 19:27 UTC
Message-ID: <20100805192723.GA10435@sigill>
In-Reply-To: <AANLkTimzn05tvwY=uG6VP6PXDHwA=wS9ECuK_9eWKtSx@mail.gmail.com>

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

Show 10 quoted lines

> 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