Re: StGit: kha/{safe,experimental} updated

From: Karl Hasselström <kha@treskal.com>
Date: May 20, 2008, 07:04 UTC
Message-ID: <20080520070441.GB7324@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0805191421n1ca676dai1b3ed7d6eb1df5f4@mail.gmail.com>

On 2008-05-19 22:21:17 +0100, Catalin Marinas wrote:

Show 15 quoted lines

> On 14/05/2008, Karl Hasselström <kha@treskal.com> wrote:
>
> > kha/safe has improved version handling: "stg --version" will now
> > present a detailed version number just like git does:
> >
> >   $ stg --version
> >   Stacked GIT 0.14.2.152.g77bd
>
> Thanks, I merged this patch. I create a similar patch some weeks ago
> (just some naming differences and only use the id of the HEAD) but
> went on holiday + a conference and forgot about it. Anyway, yours
> looks fine but I'll modify it slightly to use just 0.14.2 if a file
> named ".release" exists in the working directory. I did this with my
> patch to allow building of release tarballs without the git
> information. Do you have any better suggestion?

The system I built works like this at install time:

  i1. Create stgit/builtin_version.py, populated with git-describe
      output.

  i2. Install as usual.

And at runtime:

  r1. If we have a .git directory, ask git what version we are.
      (Actually, we just try to run git describe and see if it
      succeeds.)

  r2. Otherwise, go with the built-in version (only works if
      stgit/builtin_version.py exists).

Now, as to released versions, you could simply plop a suitably prepared stgit/builtin_version.py in the tarball, and it'll all work. i1 should fail silently when run from an unpacked tarball, so i2 will pick up the builtin_version.py from the tarball. And at runtime, r1 will fail and we'll fall back to r2.

Oh, and please consider making annotated release tags in the future. As is, I had to ask git-describe to look at unannotated tags as well, which won't be so good in case a developer uses those as a scratch pad while developing.

( The reason to do r1 before r2 is that otherwise an StGit tree will
  "stick" with the version it had at the time the last installation
  was run from that tree. We might fix that if we make sure to delete
  builtin_version.py immediately after the installation. That's
  desirable since any installed version of StGit currently runs
  git-describe unnecessarily. )

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle