On Fri, 26 Jan 2007, J. Bruce Fields wrote: > > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html