Thread (7 messages) flat view 7 messages, 2 authors, 2016-06-15

Re: Submodules with feature branches

From: W. Trevor King <hidden>
Date: 2016-06-15 23:01:29

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help