On Fri, 26 Jan 2007, J. Bruce Fields wrote:
quoted text
>
> 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.

quoted text
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html