Re: organizing multiple repositories with dependencies

From: dag@cray.com <dag@cray.com>
Date: Apr 24, 2012, 23:33 UTC
Message-ID: <nngd36w1z9n.fsf@transit.us.cray.com>
In-Reply-To: <CAE1pOi2KgeLPg7UVRP7dbqLFJErsKUx22Mi5aSkphy7KMJhoUQ@mail.gmail.com>

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

Show 11 quoted lines

>>> I'm assuming that if you have subproject S in umbrella project U and a
>>> branch "topic" in U then that same branch should exist in S.
>>
>> No, I think that is actually very rare.  If topic branches really should
>> be mirrored then U and S should be one repository.  They are too closely
>> coupled to be separated.  But see the but about git-subtree and topic
>> branches below.
>
> Too closely coupled? I do not think breaking up a project into a set
> of libraries makes everything tightly coupled. I would argue the
> opposite. :-) Anyway, you answer my concern below.

If you need the same topic branch for each component they would indeed seem to be very tightly coupled, even if the code is "physically" separated. I can't think of a situation where I would need to implement the same or similar features in multiple components where those components are not tightly coupled in some way.

> What would happen if you had a bunch of commits in the umbrella
> project and then did a push? Would that error out? Are there
> protections in place to prevent developers from making silly mistakes
> like that?

It would push to the remote/origin of the umbrella project, maintaining the same "whole project" history. It's an explicit operation to split the commits on any subproject out and push them to the subproject's origin.

So let's say you want to branch each subproject for release. You could do something like this (off the top of my head so don't copy/paste verbatim):

branch U release_X  # Create the branch in the umbrella project
work, work, work
git subtree split S1 S1_release_X  # Split commits to S1 made on
                                   # release_X branch
git subtree split S2 S2_release_X
git subtree split S3 S3_release_X
git checkout S1_release_X          # Send commits to S1 to origin,
git push origin_S1 release_X       # creating branch release_X
git checkout S2_release_X
git push origin_S2 release_X
git checkout S3_release_X
git push origin_S3 release_X

It's the split/checkout/push sequence that I'd like to optimize and make simpler.

                             -Dave