[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-libunistring] two ways to use submodules for gnulib
From: |
Bruno Haible |
Subject: |
Re: [bug-libunistring] two ways to use submodules for gnulib |
Date: |
Thu, 30 Apr 2009 00:51:35 +0200 |
User-agent: |
KMail/1.9.9 |
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