From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754500Ab2LKTdr (ORCPT ); Tue, 11 Dec 2012 14:33:47 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.162]:15114 "EHLO mo-p00-ob.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753954Ab2LKTdq (ORCPT ); Tue, 11 Dec 2012 14:33:46 -0500 X-RZG-AUTH: :P2MHfkW8eP4Mre39l357AZT/I7AY/7nT2yrT1q0ngWNsKR9Dbc7nsXB+5kjfpK+TPQ== X-RZG-CLASS-ID: mo00 Message-ID: <50C78A96.8000705@hartkopp.net> Date: Tue, 11 Dec 2012 20:33:42 +0100 From: Oliver Hartkopp User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121123 Icedove/10.0.11 MIME-Version: 1.0 To: Linus Torvalds CC: linux-kernel Subject: Re: [PATCH] Linux 3.8-merge version information References: <50C72FCC.8010401@hartkopp.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for your explanation. Indeed i was not really aware of commit counter as the first number, even if i used CONFIG_LOCALVERSION_AUTO=y for a while now. The obviously outdated Kconfig help of CONFIG_LOCALVERSION_AUTO told me: A string of the format -gxxxxxxxx will be added to the localversion if a git-based tree is found. The string generated by this will be appended after any matching localversion* files, and after the value set in CONFIG_LOCALVERSION. (The actual string used here is the first eight characters produced by running the command: $ git rev-parse --verify HEAD which is done within the script "scripts/setlocalversion".) Maybe you can integrate parts of your comprehensive answer into this help text, as it will fit better than my awkward English %-) Tnx & best regards, Oliver On 11.12.2012 19:57, Linus Torvalds wrote: > On Tue, Dec 11, 2012 at 5:06 AM, Oliver Hartkopp wrote: >> As the automatically generated git version information is misleading in the >> merge window, name the kernel in the merge window as 3.8-merge . > > This really doesn't help. > > 90% of the commits during the merge window wouldn't be based on that > Makefile change anyway, but on some much older version. So when > bisecting, for example, you'll see Makefiles with much older version > numbers, even though the commits got merged into the 3.8 merge window. > > Also, we have code to generate the version number automatically. In > particular, I encourage people to use git trees and > CONFIG_LOCALVERSION_AUTO=y, because then your /var/log/messages (and > uname -r) will contain the exact git version of your kernel. So when > you see something like > > Linux version 3.7.0-rc8-00041-gcaf491916b1c > > in your message log, you'll know that the kernel you were running back > then was 41 commits past -rc8, and had git commit ID of caf491916b1c. > And that is really useful for things like bisections ("Ok, I know it > worked three days ago - what kernel was I running then?") much more so > than a Makefile change would be (never mind how unreliable the version > info in the makefile is). > > So this is why we only change the version in the Makefile when we do a > new tagged release. > > Linus