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>
