Testing if a certain commit is in the current branch

I'm currently using the following command for this:
   git log --pretty=format:%H | grep -q '^<commit id>"

Problem is that with large repos that can be quite slow.

Is there a faster way to do the test?

TIA, FJP

Frans Pop <elendil@planet.nl> writes:

test "$(git merge-base HEAD $commit)" = "$(git rev-parse $commit)"

But this is a literal answer that could be a less than optimal solution if you are having an XY problem.

On Wednesday 27 January 2010, Junio C Hamano wrote:

Great! If the commit ID is not present that only takes 1 sec versus 11 secs for my test. (If the commit _is_ present and fairly recent my test can be faster, but 11 secs delay when it's not present hurts more.)

The use case is a wrapper script for kernel builds in which some variation are needed (due to changes in the build system) when building older kernels, e.g. during bisections or when building older stable updates. So I test for the presence of commits that introduced relevant changes.

Thanks again, FJP

Frans Pop wrote:

Neat idea.  How about this (untested)?

 git rev-list ^HEAD --no-walk commit1 commit2 ...

On Wednesday 27 January 2010, Jonathan Nieder wrote:

Does not seem to work. But I'd be interested if you find a variant that does as it's very fast.

Thanks, FJP

I've been using the following. It produces output only if the commit is NOT in HEAD.

git rev-list -1 ^HEAD commitID

-Dale

On Wednesday 27 January 2010, Dale Farnsworth wrote:

Nice. That does work.

Returns 0 in both cases and you'd need to allow for nonexisting commit IDs, 
so you'd get:
   test -z "$(git rev-list -1 ^HEAD <commit id> 2>/dev/null)"

Time needed looks to be slightly faster than Junio's test.

Thanks, FJP

On Wed, Jan 27, 2010 at 09:36:14AM +0100, Frans Pop wrote:

Isn't something very wrong if grepping the log output is faster than simple merge-base call? Can you post exact numbers?

				Petr "Pasky" Baudis

On Wednesday 27 January 2010, Petr Baudis wrote:

It's only faster if the commit is present very early in the log. The reason is probably that because of the '-q' option it does not actually read the full log, but breaks out as soon as it's found a match.

In my test I had an elapsed time of ~0.5 sec (versus 1 sec for Junio's test). And here's a grep for the very first commit:

$ time git log --pretty=format:%H | grep -q 48404cb50b0b547

real 0m0.010s user 0m0.000s sys 0m0.012s

Frans Pop <elendil@planet.nl> writes:

Not answering the question exactly, but "git branch --contains <commitid>" does almost this and a bit more.

On Wednesday 27 January 2010, Matthieu Moy wrote:

Thanks. That would work as:
   git branch --contains <commitid> | grep -q "^\*"

It's a lot slower than Junio's solution though (and even slower than my original solution).

Cheers, FJP

Hi,

On Wed, 27 Jan 2010, Frans Pop wrote:

You are more likely looking for "git branch --contains". But this gives you _more_ information.

Ciao, Dscho