Hi Michal, On Wed, Oct 23, 2013 at 03:21:00PM +0200, Michal Marek wrote: > On 13.9.2013 23:49, Afzal Mohammed wrote: > > If a private tag is created after the most recent kernelversion tag, a > > commit after this private tag would feed kernelrelease with commits > > after private tag and kernelversion tag. This may confuse user relying > > on kernelrelease (mostly a developer while debugging), mainly if HEAD > > has a private tag and otherwise w.r.t git distance from kernelversion > > tag. > > The solution is simple: Do not use private annotated tags. Or rather, if > you are creating an annotated tag, modify EXTRAVERSION accordingly. Any > automagic based on the tag name is going to fail in some way. Here private tags, although not a proper term, (my description wasn't clear) was referring to any annotated/signed tag that does not match kernelversion. Reason for this patch was to determine the exact source from kernel logs easily while working over subystem maintainer trees (especially useful when checking older logs and testing). More than my private tags, it is the tags of subystem maintainers which never is a kernelversion that made it difficult to determine the source from logs. Presence of those tags misleads one about the source. Modifying EXTRAVERSION would make it dirty, else commiting only for the sake of avoiding dirty would be required to track the git source and chances are high that git gc may eat those commits. > With your change, the script considers e.g. the next-YYYYMMDD tags > "private." Although next tags were not causing much problem (due to localversion-next file and as no direct development over next), maintainer tags like this without localversion-* files were the ones that was being mostly targeted by this change. > > define filechk_kernel.release > > - echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))" > > + echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree) $(KERNELVERSION))" > $@ > > endef > > The >$@ should not be there. Yes, crap, happened while rebasing - punishment for coding without proper understanding. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
