Re: Submodules with feature branches

["W. Trevor King" <wking@tremily.us>]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Thu, Jun 05, 2014 at 12:00:33PM -0700, W. Trevor King wrote:
> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]