On Thu, Jun 05, 2014 at 01:31:39PM -0500, Robert Dailey wrote: > On Thu, Jun 5, 2014 at 11:23 AM, W. Trevor King wrote: > > 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. If you want to add a feature to pygrader that needs tweaks to pgp-mime, you can put your public repositories somewhere as siblings, and: $ git clone --recursive git://you.net/pygrader.git will work fine (drawing from git://you.net/pgp-mime.git, etc.). > 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? Anyone reviewing your changes locally will need a way to get your submodule commits as well as your superproject commits. In both cases, they can use the usual: $ git add remote you git://you.net/….git $ git fetch or other tweaks like GitHub's refs/pull/*/head namespace [1]. Even a shared central repository, if that's how your team rolls. > 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 You can in a branch. Maybe I'm missing something here. In any case, edits to third party libs are best upstreamed ;). > * Merge conflicts are insane to resolve and involve two clones if > trunk maintainers modify third party binaries and you do as well. You resolve the merge conflicts in the submodule, and then amend the superproject merge commit to point to the resolved submodule commit. That is one --amend away from what you're doing without submodules. > * Feature branching requires those capping / meta commits to simply > setup your branch to be a feature branch. With relative URLs (or shared centralized repository, or a refs/pull/*/head namespace) it's easy to share the commits themselves. Unless you're using 'git submodule update --remote …', you don't need to care where the gitlinked commits live, you just need to get them into the submodule repository somehow. That seems fairly orthogonal to feature branching to me. > 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. If you feel that the minimal (branch + PR for changes) overhead of managing the projects independently is too high, you're probably better off with the single repository or subtree approach. Cheers, Trevor [1]: https://help.github.com/articles/checking-out-pull-requests-locally -- 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:
signature.asc
Description: OpenPGP digital signature