Re: [Sbcl-devel] git repo branch

[Nikodemus S. <nik...@ra...>]

On 8/4/07, Andreas Fuchs <as...@bo...> wrote:

> I absolutely agree with you about the niceness of numeric ordering of
> commits. It seems that so do the git gods:
>
> $ cd ~/dl/git/sbcl/
> $ tail -1 version.lisp-expr
> "1.0.3.4"
> $ git describe
> sbcl.1.0.3-4-g70ea779
>
> The format is <last tag>-<commits since last tag>-<unique substring of
> commit hash>. I think that's pretty neat (-:

What follows is a make-version.sh script, which generates a version number
using the following rules:

0. If there is no .git, there must be a version.txt file -- from
   a release tarball.

1. Get last tag, number of commits after it, and a short SHA1
   prefix.

2. The tag name must start with sbcl.<number> or <number>.

3. If the commit the tag refers to is the current HEAD (no
   commits after the tag), then the name of the tag is all
   we need.

   Otherwise, if we have a command-line argument, use it as
   a descriptive suffix.

   Otherwise, use the current branch name as a descriptive
   suffix -- unless there is no branch, or if the branch
   is "master", in which case us the "anon" suffix.

4. If there are uncommitted changes in the tree, add "dirty"
   suffix.

For the branch I'm currently sitting on this results in

  1.0.8.33-g4f54-pending

-- 1.0.8 + 33 commits, SHA1 prefix 4f54, branch name is "pending",
no uncommitted changes in tree.

I think "interim" versions like this (esp. in distributed world
where there are many possible 1.0.8 + 33 commits versions) are
always at best descriptive. The SHA1 prefix gives a good shot
at making sure you have the exact same version, but the suffix
is probably more useful for human consumption.

When using something like Git, I think adding

 sb-ext:lisp-implementation-sha1

is perfectly sane -- but it's not going to be usefull
all that often at the end, I think.

Cheers,

 -- Nikodemus

if test -d .git
then
    # Get base tag, count of commits after it, and a SHA1 prefix
    base=$(git describe --abbrev=4 | sed -E "s/^sbcl\.//")
    case "$base" in
	[0-9].*)
	    # tag.n_commits, not tag-n_commits
	    base=$(echo $base | sed -E "s/-([0-9]+-g)/.\1/")
	    ;;
	*)
	    echo "Bad base tag from git-describe: $base"
	    echo "(wanted something starting with [0-9], or sbcl.[0-9])"
	    exit 1
	    ;;
    esac
    # If the tag matches the HEAD, it should be all the information we
    # need. Otherwise add a descriptive suffix: either the
    # command-line -<argument>, or -<branch-name>, or -anon if the branch
    # name is uninformative.
    tag=$(git-describe --abbrev=0)
    tag_commit=$(git cat-file -p $tag | head -n1 | cut -d' ' -f2)
    commit=$(git rev-list --max-count=1 HEAD)
    if test "$tag_commit" = "$commit"
    then
	suffix=""
    else
	if ! test -z "$1"
	then
	    suffix="-$1"
	else
	    branch=$(git branch | grep "^\*" | cut -c3-)
	    case "$branch" in
		"(no branch)")
		    suffix="-anon"
		    ;;
		"master")
		    suffix="-anon"
		    ;;
		*)
		    suffix="-$branch"
	    esac
	fi
    fi
    # Is the tree dirty (uncommitted changes)?
    if test -z "$(git diff-index --name-only HEAD)"
    then
	dirty=""
    else
	dirty="-dirty"
    fi
    echo $base$suffix$dirty
    exit 0
else
    if test -f version.txt
    then
	# No .git, so this must be a release tarball of some sort, which
        # should have the version in version.txt
	cat version.txt
	exit 0
    else
	echo "No .git, no version.txt -- could not figure out the version."
	exit 1
    fi
fi