Re: [bug-libunistring] two ways to use submodules for gnulib

[Paolo Bonzini]

> 1) What are git submodules? I've read [2], and I think the purpose of git
>    submodules is to reference particular versions (tags) in other, public
>    git trees. Right? 

Yes with s/tags/commits/.

> 2) It is pointless to make a reference to a non-public commit in a another
>    git repository, right? Because at the moment that commit gets pushed,
>    a conflict may occur, and thus the referenced commit might actually never
>    get published.

Yes, so it's actually not pointless, but bad, because people may not be
able to reconstruct the tree.  (This only applies to projects that, like
most GNU project, rely heavily on rebasing to have a linear history.
Other projects put those non-public commits in a branch and use real
merges to fix conflicts; this means that those commits *will* be there
in the global history of the referenced submodule).

> 3) I would like to say: "For the newest version (HEAD) of libunistring,
>    always use the newest version (HEAD) of gnulib." As I understand, git
>    submodules cannot do this. I would have to do a
>    "git add gnulib; git commit gnulib" each time I use in libunistring
>    some files that are changed in gnulib HEAD. Is this correct?

Yes.  Of course you can use scriptss to do this automatically, for
example instead of "git push" in gnulib you can use a script that does

   origin=$(git rev-parse origin/master)
   git push "$@"
   git diff --quiet $origin origin/master 'lib/uni*' && \
      (cd ../libunistring/gnulib; git pull; cd ..;
       git commit gnulib -m'update gnulib')

>    (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.

This is not totally optimal, because I would like to checkout
libunistring at April 30th 2009 and see what the corresponding gnulib
HEAD was, but at least it allows me to reconstruct the public tarballs.
 Still, the uni* modules are probably way more stable (in interface and
bugginess) than any other module, so it is less important to associate
libunistring and gnulib checkouts than it is for sed, bison, coreutils
or m4.

Paolo