[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: Paolo Bonzini
Subject: Re: [bug-libunistring] two ways to use submodules for gnulib
Date: Thu, 30 Apr 2009 08:07:30 +0200
User-agent: Thunderbird (Macintosh/20090302)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]