Re: jk/tag-contains: stalled

From: Jay Soffian <jaysoffian@gmail.com>
Date: Aug 5, 2010, 20:00 UTC
Message-ID: <AANLkTinX+wwOqaTVTxsdOhrZXzsXFw819aiND63-ChLG@mail.gmail.com>
In-Reply-To: <20100805192723.GA10435@sigill>

On Thu, Aug 5, 2010 at 3:27 PM, Jeff King <peff@peff.net> wrote:

> 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".

Correct.

> 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.

Well maybe, but rev-list will already take a list of revs on stdin and you can give it --no-walk, so it has already been abused to do more than strictly list revisions. And what do you call this?

$ git rev-list --branches --no-walk --author=gitster

:-)

> 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).

Sure, and if I wanted to do that, I could've just created a bunch of temporary light-weight tags for those commits I was potentially interested in and then used tag --contains. :-)

So I don't think rev-list is such a bad place after all.

j.