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

[Bruno Haible]

Hi Paolo,

Paolo Bonzini <address@hidden> wrote in [1]:
> > Another problem: can you please switch to submodules for gnulib?

3 questions:

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? 

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.
   As a consequence, git submodules don't help people who are working
   privately on several git repositories at the same time. Right?

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?
   (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?)

Bruno


[1] http://lists.gnu.org/archive/html/bug-libunistring/2009-04/msg00011.html
[2] http://git.or.cz/gitwiki/GitSubmoduleTutorial