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,

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


[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

Reply via email to