public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.cz>
To: "Toralf Förster" <toralf.foerster@gmx.de>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>
Cc: UML devel <user-mode-linux-devel@lists.sourceforge.net>,
	linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: [uml-devel] RFC: Shouldn't "./linux --version" always print the the git commit id
Date: Wed, 06 Nov 2013 14:31:04 +0100	[thread overview]
Message-ID: <527A4498.1080609@suse.cz> (raw)
In-Reply-To: <526B940F.5090803@gmx.de>

Dne 26.10.2013 12:06, Toralf Förster napsal(a):
> On 10/26/2013 09:56 AM, Geert Uytterhoeven wrote:
>> On Fri, Oct 25, 2013 at 11:19 PM, Toralf Förster <toralf.foerster@gmx.de> wrote:
>>> $ ./linux --version
>>> 3.11.0
>>
>> If there are no additional commits on top of the tag, no number and commit
>> ID are printed. I guess the rationale is that tags are global, hence present
>> in all clones, so there's no need to tell what commit ID the tag corresponds
>> to.
>>
>>> which correlates to
>>>
>>> $ git describe
>>> v3.11
>>>
>>> $ git describe --long
>>> v3.11-0-g6e46645
>>
>> This is not UML-specific. If you want to change this, you have to involve
>> the kbuild people (CC added).
>>
> Well, the reationale behind my idea comes from the (stupid) logic of one
> of my bisect scripts. I used there the commit id derived from the UML
> linux exe as a suffix for gdb back trace files created during the bisect
> process.
> Sure - logic can be easily adapted and was in the mean while.
> But IMO it would be more stringent to have always the commit id
> presented in the version string for similar cases.

You define your own versioning scheme if you build with
CONFIG_LOCALVERSION_AUTO=n and define LOCALVERSION yourself. E.g.

echo "-g$(git rev-parse --short HEAD)" >localversion-git

or set it in kconfig or on the make commandline.

Michal

      reply	other threads:[~2013-11-06 16:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <526AD08D.10506@gmx.de>
     [not found] ` <CAMuHMdX+GtHDB5r6-oXyehbemqS36rVE=Agpi0w-6TcCPQotZQ@mail.gmail.com>
     [not found]   ` <526AE051.5020809@gmx.de>
2013-10-26  7:56     ` [uml-devel] RFC: Shouldn't "./linux --version" always print the the git commit id Geert Uytterhoeven
2013-10-26 10:06       ` Toralf Förster
2013-11-06 13:31         ` Michal Marek [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=527A4498.1080609@suse.cz \
    --to=mmarek@suse.cz \
    --cc=geert@linux-m68k.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=toralf.foerster@gmx.de \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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