Restrict the tags used to generate the version string to those that
begin with "v", since git's tags for git-core (ie. excluding git-gui)
are all of the form "vX.Y...".
This is to avoid using private tags by the user in a clone of the git
code repository, which may break certain machinery (eg. Makefile, gitk).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The next major release will be 1.6.5, hopefully with a shorter cycle
than the 1.6.4 cycle. After that in 1.7.0 we can make potentially
backward incompatible changes if necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to mark the version string with '-dirty' if the cache was not up
to date, but the only thing we want to know is if the binaries are built
from modified source. Refresh the cache to avoid false dirtyness.
Christian Jaeger noticed this issue while building under fakeroot
environment (without -u) that lies about the file ownership data.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The presence of a .git directory used to be good enough evidence that
GIT-VERSION-GEN could use 'git describe' to get a version number. But
now .git might as well be a file so the test must be extended to cater for
such setups.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rate of fixes that trickle in has slowed and we are definitely
getting there. Hopefully one final round and we will have the final
1.5.5 soon.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although everybody was quiet during the Christmas holiday, it's been
a week since -rc1, so here is -rc2.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.
David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I think we can start to slow down, as we now have covered
everything I listed earlier in the short-term release plan.
The last release 1.5.0 took painfully too long.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When somebody else extracts git tarball inside a larger project,
'git describe' would reported the version number of that upper
level project.
Sometimes, using the consistent versioning across subdirectories
of a larger project is useful, but it may not always be the
right thing to do.
This changes the script to check ./vertion file first, and then
fall back to "git describe". This way, by default, tarball
distribution will get our own version. If the upper level wants
to use consistent versioning across its subdirectories, its
Makefile can overwrite ./version file to force whatever version
number they want to give us before descending into us.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is not yet -rc1 where all new topics closes, but I think it
is getting pretty closer. I'd still want to merge updates to
fsck/prune to honor reflog entries before -rc1.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When an ancient "git" that does not understand "describe"
command is on the $PATH, "git describe" emitted a Usage message
without exiting non-zero status (which is a mistake we cannot
fix retroactively). Catch this case to make sure we do not try
using phoney multi-line string as a version number.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We ended up merging too many stuff after -rc2, so here is
another round of release candidate. Non bugfixes will be
queued to "next" from now on until a real 1.4.2 happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
GIT-VERSION-GEN can incorrectly return a default version of
"v1.3.GIT" because it tries to execute git commands using the
"git-cmd" format that expects all git commands to be in the $PATH.
Convert these to "git cmd" format so that a proper answer is
returned even when the git commands have been moved out of the
$PATH and into a $gitexecdir.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've merged everything I think is ready for 1.3.0, so this is
the final round -- hopefully I can release this with minimum
last-minute fixup as v1.3.0 early next week.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Bunch of cleanups with a few notable enhancements since
1.3.0-rc1:
- revision traversal infrastructure is updated so that
existence of paths limiters and/or --max-age does not cause
it to call limit_list(). This helps the latency working with
the command quite a bit.
- comes with updated gitk.
One notable fix is to make sure that the IO is restarted upon
signal even on platforms whose default signal semantics is not
to do so. This is the fix for the notorious "clone is broken
since 1.2.2 on Solaris" problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).
So I am clearing the deck to prepare for a 1.3.0. Remaining
wrinkles, if any, will be ironed in the "master" branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now this is really a corner case, but if you have the git source
tree from somewhere other than the official tarball, you do not
have version file. And if git-describe does not work for you
(maybe you do not have git yet), we spilled an error message
from "cat version".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 5c7d3c95 broke that by making the git-describe command part of
a pipe.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By popular demand. If you build and install such binary RPMs,
the version numbering will lose monotonicity, so you may have to
later override downgrade warnings from your packaging manager,
but as long as you are aware of that and know how to deal with it,
there is no reason for us to forbid it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we are building from a working tree with local modifications,
mark the version accordingly.
Deliberately uses '-' to prevent RPM from being built from such
a tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When producing a release tarball, include a "version" file, which
GIT-VERSION-GEN can then use to do the right thing when building from a
tarball.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I think it is probably a bug that "git non_existent_command"
returns its error message to stdout without an error, where
"git-non_existent_command" behaves differently and does return an
error.
Older versions of git did not implement "git describe" and
GIT-VERSION-GEN produces an empty version string if run on
a system with such a git installed. The consequence
is that "make rpm" fails.
This patch fixes GIT-VERSION-GEN so that it works in the
absence of a working "git describe"
Signed-off-by: John Ellson <ellson@research.att.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Note: with this commit, the GIT maintainer workflow must change.
GIT-VERSION-GEN is now the file to munge when the default
version needs to be changed, not Makefile. The tag needs to be
pushed into the repository to build the official tarball and
binary package beforehand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
