Surprising tag selection by 'git describe --contains'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxx> wrote:
> > > On Tue, Aug 14, 2012 at 01:50:11AM -0400, Gregs git-bot wrote:
> > >> commit: 5ab3633d6907018b0b830a720e877c3884d679c3
> > >> From: Hunt Xu <mhuntxu@xxxxxxxxx>
> > >> 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@xxxxxxxxxxxxxxx
> > >> Tested-by: Kris Karas <bugs-a12@xxxxxxxxxxxxxxxx>
> > >> Signed-off-by: Hunt Xu <mhuntxu@xxxxxxxxx>
> > >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > >> ---
> > >>  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.

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]