Re: Submodules with feature branches

From: Robert Dailey <rcdailey.lists@gmail.com>
Date: Jun 5, 2014, 18:31 UTC
Message-ID: <CAHd499CBAQHG4rdojb8pdjymUCaZNYSnKb-ksmsLesq73OWTyA@mail.gmail.com>
In-Reply-To: <20140605162333.GR21803@odin.tremily.us>

On Thu, Jun 5, 2014 at 11:23 AM, W. Trevor King <wking@tremily.us> wrote:

Show 11 quoted lines

> 3rd party libraries sound loosely-coupled to me ;).  In one of my more
> mature projects I did a similar thing, and just used relative URLs [1]
> and sibling mirrors/forks [2,3,4].
>
> Cheers,
> Trevor
>
> [1]: https://github.com/wking/pygrader/blob/master/.gitmodules
> [2]: https://github.com/wking/pgp-mime
> [3]: https://github.com/wking/pyassuan
> [4]: https://github.com/wking/jinja2

I guess I'm still confused on how relative URLs help here. Won't the capping commits (A and C in your first email) still be needed? Or is there a way I can modify the local "../third-party.git" submodule repo instead? Can you explain?

Unfortunately, the reason why I feel third party in a submodule creates tight coupling is because:

* You can't make changes to third party libs for your feature branch
without breaking the trunk
* Merge conflicts are insane to resolve and involve two clones if
trunk maintainers modify third party binaries and you do as well.
* Feature branching requires those capping / meta commits to simply
setup your branch to be a feature branch.

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.

It just seems like a mess :-(