[Xcb] Are the util-common-m4 submodules relative on purpose?

[Dirk Wallenstein]

On Wed, Apr 06, 2011 at 08:40:08PM -0400, Gaetan Nadon wrote:
>    On Wed, 2011-04-06 at 19:10 +0200, Dirk Wallenstein wrote:
> 
>      I've added a section to the wiki here [1].  Attached is a x-jhbuild
>      plug-in to adapt the submodules in one call.
> 
>    Are you sure it is the simplest way? Cloning the repository and
>    changing URLs?
>    Consider this scenario where you want to develop a new macro to be used
>    by all supermodule. You develop and test the new macro in any of the
>    submodules (they are all identical copies). You create a patch which
>    you then apply to all remaining copies of the submodules and you test
>    it there as well. Everything has been tested everywhere.
>    The rest is the same, review and push the patch to the m4 module and
>    patch all supermodules so they point to the new m4 commit. This is what
>    I have done and it did not looked too complicated. There is a bit of
>    learning curve, but supermodules and just modules, but with a pointer
>    to a specific commit of another module.
>    The key here is that you can do the development from any copy of the
>    submodule and create patches and even push them from there (need to
>    change the url for that).
>    Gaetan

The use case I was thinking about was when you really work with the
submodule (create and merge branches, rebase, etc).  There is just one
real repository of the submodule in which all the work is done (I see
that as an advantage -- in particular the realness), and supermodules
just reference revisions.  No question, there can be a patch based
workflow for all that without having the real repository of the
submodule around, but for anything that surpasses rock-solid single shot
patches, that is just tedious, in my opinion.

I think the "working inside the submodule" approach is only useful if the
submodule is not shared by multiple supermodules.  And even then there
is always the possibility of loosing work in the air (for example, check
out a revision in the supermodule where the submodule did not exist;
return; unpublished work is gone)

But you are right, I should add the "working inside the submodule"
approach as an alternative and remove my assertion of what's best.

 * Applying changes to a submodule
    + Working from within a submodule
    + Using a local clone of a submodule

-- 
Cheers,
  Dirk