Ask a kernel developer: maintainer workflow

Quick aside: I recommend git tag --contains over git describe --contains. The former dumps all tags that a patch is in and hence needs some human parsing (or a script to dig out the right linux release).

But git describe can get confused, especially if the patch is part of a -next tree that gets pulled in much later in the next kernel release, so that e.g. 3.5-rc1 is further away than 3.6-rc1 and hence git describe leads you to believe the patch was merged for 3.6 but really is part of 3.5. Happened just recently with a drm/i915 patch that Greg at first refused to apply to the 3.5 stable queue ;-)