Re: finding earliest tags descended from a given commit

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 27, 2007, 04:34 UTC
Message-ID: <Pine.LNX.4.64.0701262022230.25027@woody.linux-foundation.org>
In-Reply-To: <20070127040618.GA14205@fieldses.org>

On Fri, 26 Jan 2007, J. Bruce Fields wrote:

Show 5 quoted lines

>
> Just curious: every now and then somebody will ask me what kernel
> version they need to upgrade to to get some given fix.  I can find the
> commit with the given fix easily enough.  How do I then find the
> earliest tagged version containing that fix?

You can name any revision based on the set of tags you have with:

	git name-rev --tags <sha1-of-commit>

which will try to find the "simplest" way to name something by following one of your tags.

If no tag can be found that reaches that commit, it will say

	<sha1> undefined

but otherwise you will get something like this:

	[torvalds@woody linux]$ git name-rev --tags 7658cc28
	7658cc28 tags/v2.6.20-rc3^0~58

(That's the "VM: Fix nasty and subtle race in shared mmap'ed page writeback commit").

So that basically tells you that it's the 58'th parent of v2.6.20-rc3, ie it was in -rc3, but not in -rc2.

Show 7 quoted lines

> I usually just do
> 
> 	git-describe <commit>
> 
> to make a guess, then
> 
> 	git log <tag>..<commit>

Yeah. That mostly works too, and kind of for the right reason: it's a related operation. But as you can tell, git-describe tells you which version somethign is *based* on, not when it was merged, so while it gives you a starting point for your search, it's not what you want.

Basically 'git descibe' goes the "other way": it walks backwards from the commit to the nearest tag that can be found, while 'git name-rev --tags' walks the history backwards from the tags, and tries to find the commit.

NOTE! 'git name-rev' can in theory be quite expensive, although if you have a packed repository you'll probably never even notice it.

		Linus