2008/5/20 Karl Hasselström <kha@xxxxxxxxxxx>: > 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. Fine (with some notes for releases, see below). > 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). OK. > 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. I build release tarball from the directory under Git control and I always get a builtin_version.py generated. In my initial patch I had a check in setup.py for a .release file. I could add a check in write_builtin_version to ignore the extra .git stuff if I am making a release (only keep the tag name). Another alternative is to check for the number of commits from the latest tag and, if this is 0, simply ignore the Git id. BTW, Git seems to use 6 characters for the current commit id and StGIT 5. Should we change this for consistency? > 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. I always thought annotated tags are created by default. I'll do this from now on. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
