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

[Dirk Wallenstein]

On Thu, Apr 07, 2011 at 09:53:58AM +0200, Dirk Wallenstein wrote:
> 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
I've added this section but I'm not really an expert with this approach.
Improvements are welcome.

-- 
Cheers,
  Dirk