ff12a7954c
As in2a5fcfae02and in3e67e5c992using /usr/bin/env allows bash to be looked up in PATH rather than being hard-coded. As with the previous changes the same arguments apply - distributions have scripts to rewrite shebangs on installation and they know what locations to rely on. - For tests/compilation we should rather rely on the user to have setup there PATH correctly. In particular this makes testing from git easier on NixOS where do not provide /bin/bash to improve compose-ability.
23 lines
623 B
Bash
Executable file
23 lines
623 B
Bash
Executable file
#!/usr/bin/env bash
|
|
|
|
set -eu
|
|
set -o pipefail
|
|
|
|
dir="$1"
|
|
tag="$2"
|
|
fallback="$3"
|
|
|
|
if [ -n "$tag" ]; then
|
|
echo "$tag"
|
|
exit 0
|
|
fi
|
|
|
|
# Apparently git describe has a bug where it always considers the work-tree
|
|
# dirty when invoked with --git-dir (even though 'git status' is happy). Work
|
|
# around this issue by cd-ing to the source directory.
|
|
cd "$dir"
|
|
# Check that we have either .git/ (a normal clone) or a .git file (a work-tree)
|
|
# and that we don't get confused if a tarball is extracted in a higher-level
|
|
# git repository.
|
|
[ -e .git ] && git describe --abbrev=7 --dirty=+ 2>/dev/null | sed 's/^v//' || echo "$fallback"
|