Re: Submodules with feature branches

From: W. Trevor King <wking@tremily.us>
Date: Jun 5, 2014, 15:15 UTC
Message-ID: <20140605151549.GQ21803@odin.tremily.us>
In-Reply-To: <CAHd499Bn7CCVy=vhFzpLYXCssxR0oGxm3Vdgou_Yk5zSt1gfmA@mail.gmail.com>

On Thu, Jun 05, 2014 at 09:03:25AM -0500, Robert Dailey wrote:

Show 7 quoted lines

> When I work on a feature, I normally create a feature branch. If I
> happen to make changes to the submodule that only work with the
> changes introduced in my feature branch, that seems to complicate
> things. For the purposes of the feature branch, do I need to create
> a corresponding feature branch in the submodule and temporarily
> update the submodule URL to point to it? When I merge my feature
> branch, I'd have to swap it back?

So you have:

  On the trunk host:   On your public host:   Locally:
  superproject         superproject           superproject
  submodule            submodule              `-- submodule

In that case, a corresponding feature branch to the submodule, and an update to submodule.<name>.url (and possibly submodule.<name>.branch) would be the way I'd go (at A in the figure below). Once the trunk maintainers were happy with things, they could merge the submodule branch into trunk's submodule (at B in the figure below), and you could add a capping commit to your superproject branch that reverted the gitmodule changes (at C in the figure below):

  -o---o---o---o-------o  trunk's superproject/master
    \                 /
     A---o---o---o---C    your superproject/feature

  -o---o-----------B  trunk's submodule/master
    \             /
     o---o---o----    your submodule/feature

An alternative is to use relative URLs in the trunk:

  superproject$ cat .gitmodules
  [submodule "bpl-subset"]
    path = submod
    url = ../submodule

which makes it easier for folks who mirror/fork both the superproject and submodule (no need to change submodule.<name>.url). However, it makes it harder for folks who just mirror/fork the superproject (and don't need to tweak the submodule), because they have to mirror/fork the submodule as well to support the relative URL (or edit submodule.<name>.url, which turns attempted mirrors into forks). Personally, I prefer relative URLs [1,2], but both external projects I've approached on this front have ended up with absolute URLs [3,4] ;).

This is less of an issue for loosely-coupled submodules, since you'll can motivate your submodule changes to the submodule maintainers independent of the superproject (i.e. you can just say things like “I'm extending the API so I can iterate over widgets. This lets you do things like frobbling whatsits in superproject” without having to present the associated superproject code). Once you land the submodule changes upstream, your superproject branch will work without the need to tweak the URL (for absolute URLs) or publish a sibling mirror (for relative URLs).

Cheers, Trevor

[1]: https://github.com/inducer/pycuda/pull/21 [2]: http://thread.gmane.org/gmane.comp.python.ipython.devel/10287/focus=10299 [3]: https://github.com/wking/pycuda/commit/5218bd449d6aae0bce3a3d1bf54a91377445e2f9 [4]: https://github.com/minrk/ipython/commit/4fe230e96e357b3612b6fadaeec9d8de71d6fca9

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy