Re: jk/tag-contains: stalled

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

On Thu, Aug 5, 2010 at 3:06 PM, Jeff King [off-list ref] wrote:

quoted

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