git had a CVE related to arbitrary code being run when you run git status and similar, and instead of doing something about those arbitrary code bits they decided to lock it down entirely.
So now git will refuse to do basically anything once it detects the .git directory is owned by someone else.
So, what we do is:
If `git describe` failed with a status of 128, we keep an already
built version file.
This is an awful hack, but should help with the normal `cmake; make; sudo
make install` cycle.
(the only *real* way around this seems to be to not attempt to rebuild
the version file at install time entirely, but I have no idea how to
do that)
Fixes#8973.
$GIT_DIR is interpreted by git as an environment variable, pointing at the
.git directory. If git_version_gen.sh is run in an environment with an
exported GIT_DIR, it will re-export GIT_DIR to point at the fish source
directory. This will cause git operations to fail.
This could be reproduced as building fish as part of an interactive rebase
'exec' command. git_version_gen.sh would always fail!
I can't seem to find a reason why the shell interpreter needs to be bash
and not just sh here. Needed to replace `BASH_SOURCE[0]` with the legacy
`$0` supported by sh, but otherwise it seems to still work.
Many non-Linux platforms do not ship with bash out-of-the-box (and as a
shell, I don't think we need to encourage the further proliferation of
bash ;-), this lets fish build on a clean install of FreeBSD, which does
not have bash.
This untangles the CMake versioning issues (I hope) as discussed in #4626.
Note most of the advice found on the Internet about how to inject git
versions into CMake is just wrong.
The behavior we want is to unconditionally run the script
build_tools/git_version_gen.sh at build time (i.e. when you invoke ninja or
make, and not when you invoke cmake, which is build system generation time).
This script is careful to only update the FISH-BUILD-VERSION-FILE if the
contents have changed, to avoid spurious rebuilding dependencies of
FISH-BUILD-VERSION-FILE. Assuming the git version hasn't changed, the script
will run, but not update FISH-BUILD-VERSION-FILE, and therefore
fish_version.o will not have to be rebuilt.
This might normally rebuild more than is necessary even if the timestamp is
not updated, because ninja computes the dependency chain ahead of time. But
Ninja also supports the 'restat' option for just this case, and CMake is rad
and exposes this via BYPRODUCTS. So mark FISH-BUILD-VERSION-FILE as a
byproduct and make the script always update a dummy file
(fish-build-version-witness.txt). Note this is the use case for which
BYPRODUCTS is designed.
We also have fish_version.cpp #include "FISH-BUILD-VERSION-FILE", and do a
semi-silly thing and make FISH-BUILD-VERSION-FILE valid C++ (so there's just
one version file). This means we have to filter out the quotes in other
cases..
This adds support for creating the FISH-BUILD-VERSION-FILE in the CMake
build. A FISH-BUILD-VERSION-FILE is created in the CMake directory
and only updated when necessary.
This reverts functional changes in commit
3bef4a3c1f.
* Annotated tags only should be used for releases - see #3572 for
examples of where we want to use lightweight tags.
See also git-tag(1) on the purpose of annotated and lightweight tags.
* Version numbers are numbers and should not start with a branch name.
The commit ID is embedded in the version and uniquely identifies the
history. `fish --version` and `echo $FISH_VERSION` contain this
information.
Now that we're working on the 3.0.0 major release it is more important
than ever that fish binaries built by developers have version strings
which clearly communicate where they came from.
When calculating the version, we don't need to test for the presence of
.git before running `git describe`. This lets us work properly in a
detached work tree if GIT_DIR is set.
Note: if you have previously cloned the repository, the tags for
previous versions have been edited. Use `git fetch --tags` to
synchronise your local copy.