From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
To: Michal Marek <mmarek@suse.cz>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
Christian Kujau <lists@nerdbynature.de>
Subject: Re: [PATCH RFC] kbuild: prevent git private tag altering kernelrelease
Date: Mon, 28 Oct 2013 01:09:07 +0530 [thread overview]
Message-ID: <20131027193907.GA2710@afzal-ThinkPad-R50e> (raw)
In-Reply-To: <5267CD3C.2020004@suse.cz>
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
prev parent reply other threads:[~2013-10-27 19:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 21:49 [PATCH RFC] kbuild: prevent git private tag altering kernelrelease Afzal Mohammed
2013-10-23 13:21 ` Michal Marek
2013-10-27 19:39 ` Afzal Mohammed [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131027193907.GA2710@afzal-ThinkPad-R50e \
--to=afzal.mohd.ma@gmail.com \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@nerdbynature.de \
--cc=mmarek@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox