# Surprising tag selection by 'git describe --contains'

1 messages from 2012-08-18 to 2012-08-18. Participants: Ben Hutchings.
Thread: https://gitlist.dev/t/31275

## Ben Hutchings, 2012-08-18 00:13

Subject: Surprising tag selection by 'git describe --contains'
Message-ID: <1345248826.4986.33.camel@deadeye.wl.decadent.org.uk>
URL: https://gitlist.dev/e/1345248826.4986.33.camel%40deadeye.wl.decadent.org.uk
In-Reply-To: <20120817132250.GA28980@kroah.com>

```
On Fri, 2012-08-17 at 06:22 -0700, Greg KH wrote:
> On Fri, Aug 17, 2012 at 09:18:44AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 17, 2012 at 1:18 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Tue, Aug 14, 2012 at 01:50:11AM -0400, Gregs git-bot wrote:
> > >> commit: 5ab3633d6907018b0b830a720e877c3884d679c3
> > >> From: Hunt Xu <mhuntxu@gmail.com>
> > >> Date: Sun, 1 Jul 2012 03:45:07 +0000
> > >> Subject: drm/i915: make rc6 in sysfs functions conditional
> > >>
> > >> Commit 0136db586c028f71e7cc21cc183064ff0d5919c8 merges rc6 information
> > >> into the power group. However, when compiled with CONFIG_PM not set,
> > >> modprobing i915 would taint since power_group_name is defined as NULL.
> > >>
> > >> This patch makes these rc6 in sysfs functions conditional upon the
> > >> definition of the CONFIG_PM macro to avoid the above-mentioned problem.
> > >>
> > >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181
> > >> Cc: stable@vger.kernel.org
> > >> Tested-by: Kris Karas <bugs-a12@moonlit-rail.com>
> > >> Signed-off-by: Hunt Xu <mhuntxu@gmail.com>
> > >> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > >> ---
> > >>  drivers/gpu/drm/i915/i915_sysfs.c |   12 ++++++++++++
> > >>  1 files changed, 12 insertions(+), 0 deletions(-)
> > >
> > > As commit 0136db586c028f71e7cc21cc183064ff0d5919c8 only first showed up
> > > in 3.6-rc1, is this patch still needed for the stable tree(s)?
> > 
> > 
> > My git tag --contains claims it's in 3.5 already.
> 
> Really?
> 
> $ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919c8
> v3.6-rc1~59^2~56^2~76
> 
> Do you see something else?

'git describe --contains' seems to choose the containing tag whose tree
has the shortest path from the given tree-like.  So, when some branch
has relatively few changes after Linus pulls it for release N and before
he pulls it for release N+1 *and* he pulls it later in the merge window
for release N+1, commits include in v3.N-rc1 can still be closer to
v3.(N+1)-rc1 because the extra merge commits on the path to v3.N-rc1
outweigh the extra non-merge commits on the path to v3.(N+1)-rc1.

git certainly doesn't (and shouldn't) know anything about ordering of
tag names, but I think that if one of the containing tags is the
ancestor of all the others then 'git describe --contains' should prefer
to use that.  Or at least, there should be some way to request that
behaviour.

For now, if in doubt, 'git tag --contains' will tell you all the
containing tags.

Ben.

> > And people have reported the regressions to prove it ;-)
> 
> Ok, fair enough, I'll apply it.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.

```