Paolo Bonzini wrote:
> at least it allows me to reconstruct the public tarballs.
That is all that you want? I'll store the reference like this:
*** version.sh.orig 2009-05-01 18:46:48.000000000 +0200
--- version.sh 2009-05-01 18:46:32.000000000 +0200
***************
*** 1,3 ****
--- 1,6 ----
# Version number and release date.
VERSION_NUMBER=0.9
RELEASE_DATE=2009-04-26 # in "date +%Y-%m-%d" format
+
+ # Version of gnulib that was used in this release.
+ GNULIB_GIT_COMMIT=13a006f97fca894168e4c1aedfa780f83717c78c
> I would like to checkout
> libunistring at April 30th 2009 and see what the corresponding gnulib
> HEAD was
The answer is: You need the gnulib HEAD from Aprit 30th 2009 as well.
This is implicitly clear from the comments in autogen.sh.
> > (Is that the reason why in your second recipe, you limit the scope of
> > the .gitmodules file and the gnulib submodule to the 'releases' branch?)
>
> Yes, this limits the presence of submodules to the releases branch and
> hence to tags.
OK, but then I don't see the point of using git submodules for this
feature. If I did, then
- I would have to update regularly the reference to the latest gnulib,
whereas the rule "newest libunistring needs newest gnulib" already
says everything.
- The git history would become nonlinear and confusing, with releases
occurring on a particular branch only.
- Users of my development tree would have to learn about git submodules.
I'm committing this to version.sh and HACKING.
Bruno
*** version.sh.orig 2009-05-01 19:00:51.000000000 +0200
--- version.sh 2009-05-01 18:46:32.000000000 +0200
***************
*** 1,3 ****
--- 1,6 ----
# Version number and release date.
VERSION_NUMBER=0.9
RELEASE_DATE=2009-04-26 # in "date +%Y-%m-%d" format
+
+ # Version of gnulib that was used in this release.
+ GNULIB_GIT_COMMIT=13a006f97fca894168e4c1aedfa780f83717c78c
*** HACKING.orig 2009-05-01 19:00:51.000000000 +0200
--- HACKING 2009-05-01 19:00:14.000000000 +0200
***************
*** 36,46 ****
--- 36,54 ----
http://www.perl.org/
* Either an internet connection or a recent copy of GNU gnulib.
+ In order to work with the HEAD of libunistring development, you need the
+ HEAD of the gnulib development.
+ In order to work with the version of libunistring at a given date, you
need
+ the version of gnulib of the same date.
+ In order to work with a released tarball of libunistring, you need the
+ particular version of gnulib which is indicated in the GNULIB_GIT_COMMIT
+ variable in version.sh.
+ Homepage:
http://www.gnu.org/software/gnulib/
And, of course, the packages listed in the DEPENDENCIES file.
+ Then you can run the 'autogen.sh' script
Sources
=======
