I just stumbled across another[0] issue when scripts/setlocalversion
operates on a write-protected source tree. Back then[0] the source tree
was on an read-only NFS share, so "test -w" was introduced before "git
update-index" was run.

This time, the source tree is on read/write NFS share, but the permissions
are world-readable and only a specific user (or root) can write.
Thus, "test -w ." returns "0" and then runs "git update-index",
producing the following message (on a dirty tree):

  fatal: Unable to create '/usr/local/src/linux-git/.git/index.lock': Permission denied

While it says "fatal", compilation continues just fine.

However, I don't think a kernel compilation should alter the source
tree (or the .git directory) in any way and I don't see how removing
"git update-index" could do any harm. The Mercurial and SVN routines in
scripts/setlocalversion don't have any tree-modifying commands, AFAICS.
So, maybe the patch below would be acceptable.

[0] https://patchwork.kernel.org/patch/29718/Signed-off-by: NChristian Kujau <lists@nerdbynature.de>
Cc: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

This patch allows the use of setlocalversion script regardless of the language
parameters. Otherwise, the `svn info 2>/dev/null | grep '^Last Changed Rev'`
returns nothing because for instance, in French the text 'Last Changed Rev'
is replaced by 'Révision de la dernière modification'
Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

In some circumstances (eg when running a build in an emacs shell
buffer), I get a spew of messages like

    grep: writing output: Broken pipe

from setlocalversion, because the "read" subshell apparently exits as
soon as it reads one line and gives EPIPE to grep.  It's not clear to
me why this way of writing the check was used instead of just using
grep -q to suppress output, but unless there is some deep reason I
don't know, this way looks cleaner to me anyway, and gets rid of the
ugly message spew.

(I double checked at http://pubs.opengroup.org/onlinepubs/009604499/utilities/grep.html
and "grep -q" is specified in POSIX / SuS, so hopefully even people
cross-compiling the kernel on some bizarre host OS can't complain
about this change)
Signed-off-by: NRoland Dreier <roland@purestorage.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

The tag output of hg doesn't quite match what setlocalversion currently
expects, so update it to handle the latest format.
Signed-off-by: NMike Crowe <mcrowe@zipitwireless.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

A tagged repository state isn't enough, git describe only
looks at signed or annotated tags (git tag -a/-s). This
documentation update makes sure the comment matches the
current behaviour.
Signed-off-by: NMichael Prokop <mika@grml.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Dan McGee <dpmcgee@gmail.com> writes:
> Note that when in git, you get the appended "+" sign. If
> LOCALVERSION_AUTO is set, you will get something like
> "eee-gb01b08c-dirty" (whereas the copy of the tree in /tmp still
> returns "eee"). It doesn't matter whether the working tree is dirty or
> clean.
>
> Is there a way to disable this? I'm building from a clean tarball that
> just happens to be unpacked inside a git repository. One would think
> setting LOCALVERSION_AUTO to false would do it, but no such luck...

Fix this by checking if the kernel source tree is the root of the git or
hg repository. No fix for svn: If the kernel source is not tracked in
the svn repository, it works as expected, otherwise determining the
'repository root' is not really a defined task.
Reported-and-tested-by: NDan McGee <dpmcgee@gmail.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

The manpage for cut says it will return all lines without the delimiter
unless -s is specified.

When I backed up my mecurial tree to generate modules, I found that the
scm part of localversion was turning up blank.
Signed-off-by: NMilton Miller <miltonm@bga.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: "Michał Górny" <gentoo@mgorny.alt.pl>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

make rpm was broken by commit 09155120:
make clean
set -e; cd ..; ln -sf /usr/src/iwlwifi-2.6 kernel-2.6.35rc4wl
/bin/sh /usr/src/iwlwifi-2.6/scripts/setlocalversion --scm-only >
/usr/src/iwlwifi-2.6/.scmversion
cat: .scmversion: input file is output file
make[1]: *** [rpm] Error 1
Reported-and-tested-by: N"Zheng, Jiajia" <jiajia.zheng@intel.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

The 'source' builtin is a bash alias to the '.' (dot) builtin. While the
former is supported only by bash, the latter is specified in POSIX and
works fine with all POSIX-compliant shells I am aware of.

The '$_' special parameter is specific to bash. It is partially
supported in dash too but it always evaluates to the current script path
(which causes the script to enter a loop recursively re-executing
itself). This is why I have replaced the two occurences of '$_' with the
explicit parameter.

The 'local' builtin is another example of bash-specific code. Although
it is supported by all POSIX-compliant shells I am aware of, it is not
part of POSIX specification and thus the code should not rely on it
assigning a specific value to the local variable. Moreover, the 'posh'
shell has a limited version of 'local' builtin not supporting direct
variable assignments. Thus, I have broken one of the 'local'
declarations down into a (non-POSIX) 'local' declaration and a plain
(POSIX-compliant) variable assignment.
Signed-off-by: NMichał Górny <gentoo@mgorny.alt.pl>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Now that we run scripts/setlocalversion during every build, it makes
sense to move all the localversion logic there. This cleans up the
toplevel Makefile and also makes sure that the script is called only
once in 'make prepare' (previously, it would be called every time due to
a variable expansion in an ifneq statement). No user-visible change is
intended, unless one runs the setlocalversion script directly.
Reported-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Do not update index on read only media.
Idea published by Christian Kujau <lists@nerdbynature.de>.

Cc: Nico Schottelius <nico@ikn.schottelius.org>
Cc: Christian Kujau <lists@nerdbynature.de>

Produce correct output for
- tagged commit (v2.6.30-rc6)
- past tagged commit (v2.6.30-rc5-299-g7c7327d9)
- no tag
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When using trees like wireless-testing, which have untagged tags,
scripts/setlocalversion does not display any git indication for
localversion.

This patch fixes it: If git is available, but no usable tag is found,
it uses -g${head}. It skips the detection of unanottated tags via
git name-rev.
Signed-off-by: NNico Schottelius <nico@ikn.schottelius.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Use the correct git <subcmd> syntax instead of the deprecated git-<subcmd>.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Don't bother doing `svn st` as it takes a retarded amount of time when
the source is cold
Signed-off-by: NMike Frysinger <vapier.adi@gmail.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Print svn revision in addition to git info on git-svn repos.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Output svn revision of latest change, instead of repo revision as thats
what we're interested in (especially when working on a branch/tag).
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

setlocalversion used to use an abbreviated git commit sha1 to generate the
tag.  This was changed in commit d882421f
"kbuild: change CONFIG_LOCALVERSION_AUTO to use a git-describe-ish format"
to use git describe to come up with a tag.  Which is nice, but git describe
sometimes can't describe the revision.
Commit 56b2f070 ("setlocalversion: do not
describe if there is nothing to describe") addressed this, but there is still
no tag generated.

So, generate a plain abbreviated sha1 tag like setlocalversion used to when
git describe comes up short.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
CC: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

The number of pending changes is pretty useless, so encoding it into the
version is just annoying by the constant shuffle in corresponding modules.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Jan Engelhardt wrote:
> Just a note that when you run git-describe, you should probably quiten it.
>
> fatal: cannot describe 'bd7364a0fd5a4a2878fe4a224be1b142a4e6698e'
>
> This happens when tags are not present, which can happen if Linus's tree
> is sent upwards again, IOW:
>
>  machine1$  git-clone torvalds/linux-2.6.git
>  machine1$  git push elsewhere master
>
>  machine2$  git-clone elsewhere:/linux
>  machine2$  git-describe HEAD
>  fatal: cannot describe that
Signed-off-by: NSebastian Siewior <sebastian@breakpoint.cc>
Acked-by: NJan Engelhardt <jengelh@medozas.de>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

follow git and mercurial style, include uncommitted changes detect

Cc: Frans Pop <elendil@planet.nl>
Signed-off-by: NBryan Wu <bryan.wu@analog.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

make-kpkg modifies scripts/package/Makefile and deletes
scripts/package/builddeb as part of its build process.  Ignore these
changes so the tree isn't marked as -dirty, when it is just an
artifact of make-kpkg.  (make-kpkg clean restores the files to their
original state, and these helper scripts won't affect the final
compiled kernel in any way.)
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

If git's index file is out of date, and some files have been touched
such that their timestamp doesn't what is in the index, "git
diff-index HEAD" may show that a particular file is dirty, when in
fact it really isn't.  Running "git update-index" will update the
index to avoid these false positives.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Change the automatic local version to have the form -nnnnn-gSHA1SUMID,
where 'nnnnn' is the number of commits since the last tag (i.e.,
2.6.21-rc7).  This makes it much more likely that the package names created
for the kernel will look "newer" to a package manager.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

This represents mercurial changesets similarly to git.  For untagged
revisions, append the changeset id.  If there are uncommitted changes,
append -dirty.  For example, -hgc60016ba6237-dirty
Signed-off-by: NAron Griffis <aron@hp.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Compare the working copy with the last commit, instead of the index.
Signed-off-by: NUwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Acked-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

adds revision suffix for untagged commits that are reachable from a tag

I'm bisecting and don't get the -g...... suffix.  The reason is, that

	git name-rev --tags HEAD

returns e.g.

	HEAD tags/v2.6.17-rc1^0~1067

which is currently good enough for setlocalversion to skip the suffix.
This introduces a dependecy to grep -E, which should be fine.
Signed-off-by: NUwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Acked-By: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

When building Debian packages directly from the git tree, the appended
"git_dirty" is a problem due to the underscore.  In order to cause the
least problems, change that just to "dirty".
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Currently scripts/setlocalversion is a Perl script that tries to figure
out the current git commit ID of a repo without using git.  It also
imports Digest::MD5 without using it and generally is too big for the
small task it does. :]  And it always reports a git ID, even when the
HEAD is tagged -- this is a bug.

This patch replaces it with a Bourne Shell script that uses git
commands to do the same.  I can't come up with a scenario where someone
would use a git repo and refuse to install git core at the same time,
so I think it's reasonable to assume git is available.

The new script also reports uncommitted changes by adding -git_dirty to
the version string.  Obviously you can't see from that _what_ has been
changed from the last commit, so it's more of a reminder that you
forgot to commit something.

The script is easily extensible: simply add a check for Mercurial (or
whatever) below the git check.

Note: the script doesn't print a newline char anymore.  That's only
because it was easier to implement it that way, not a feature (or bug).
'make kernelrelease' doesn't care.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

If CONFIG_AUTO_LOCALVERSION is set, the user is using a git-based tree, and the
current HEAD is not referred to by any tags in .git/refs/tags/, append -g and
the first 8 characters of the commit to the version string.  This makes it
easier to use git-bisect, and/or to do a daily build, without trampling on your
older, working builds, or accidentally setting up conflicting sets of modules.
Signed-off-by: NRyan Anderson <ryan@michonline.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>