Re: Why is "git tag --contains" so slow?
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Jul 1, 2010, 01:00 UTC
- Message-ID
- <AANLkTikkLIKm3soF9agXnN34P7Xnq4AiVqGU_qFaaRmZ@mail.gmail.com>
- In-Reply-To
- <E1OU82h-0001xY-3b@closure.thunk.org>
On Wed, Jun 30, 2010 at 8:54 PM, Theodore Ts'o <tytso@mit.edu> wrote:
Show 10 quoted lines
> I'm trying to write a script that can determine the first kernel release > (i.e., a tag of that matchs v2.6.*) that contains a particular commit. > > I can do this using "git tag --contains <commit-id>", but it's quite > slow. It takes something like 8-9 seconds. (8.5 seconds of user time, > 8.6 times of wall clock, to be precise). > > I can get the information much faster using "gitk -1 <commit-id>", which > finishes painting the screen in under 2 seconds, but that throws up a > GUI and then a human has to pull the information out using their eyes.
There's a big difference between the two: the gitk command you're using only works if the given commit is *itself* named by a tag, while 'git tag --contains' needs to search the entire history of every tag to see if the given commit is *inside* it somewhere.
If all you want is to see if a given commit exactly matches a tag, perhaps you want something like
git describe --exact-match <commit-id>
Have fun,
Avery