Re: Submodules with feature branches

From: W. Trevor King <wking@tremily.us>
Date: Jun 5, 2014, 19:18 UTC
Message-ID: <20140605191829.GA32192@odin.tremily.us>
In-Reply-To: <20140605190033.GV21803@odin.tremily.us>

On Thu, Jun 05, 2014 at 12:00:33PM -0700, W. Trevor King wrote:

Show 10 quoted lines

> On Thu, Jun 05, 2014 at 01:31:39PM -0500, Robert Dailey wrote:
> > Instead of just creating my branch and starting to make commits, I
> > now have to setup my submodule branch first. Also pull requests
> > won't show the changes to the third party libraries unless I do a
> > second pull request for the third party repo.
> 
> That I agree with ;).  However, if you're treating the third-party
> library as a separate repo, I think it makes sense that you need to
> be making branches and pull requests in the submodule independently
> from your branches and pull requests in the superproject.

To make this more concrete, I think you'll rarely have tight one-to-one binding between third-party library changes and your superproject. More likely, you'll have some high-level feature branch in the superproject (“accept comments via email”) and an unrelated number of prerequisite feature branches for your libraries (“add support for MIME documents,” “parse RFC 2822 dates,” …). You only have synchronized branches when you mess with the API tying components together (updating the submodule API and updating the superproject to use it). With good library design, that type of API migration should happen more and more rarely as the library stabilizes.

Cheers, Trevor

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