On Thu, Jun 5, 2014 at 10:15 AM, W. Trevor King <wk...@tremily.us> wrote:
> So you have:
>   On the trunk host:   On your public host:   Locally:
>   superproject         superproject           superproject
>   submodule            submodule              `-- submodule
> In that case, a corresponding feature branch to the submodule, and an
> update to submodule.<name>.url (and possibly submodule.<name>.branch)
> would be the way I'd go (at A in the figure below).  Once the trunk
> maintainers were happy with things, they could merge the submodule
> branch into trunk's submodule (at B in the figure below), and you
> could add a capping commit to your superproject branch that reverted
> the gitmodule changes (at C in the figure below):
>   -o---o---o---o-------o  trunk's superproject/master
>     \                 /
>      A---o---o---o---C    your superproject/feature
>   -o---o-----------B  trunk's submodule/master
>     \             /
>      o---o---o----    your submodule/feature
> An alternative is to use relative URLs in the trunk:
>   superproject$ cat .gitmodules
>   [submodule "bpl-subset"]
>     path = submod
>     url = ../submodule
> which makes it easier for folks who mirror/fork both the superproject
> and submodule (no need to change submodule.<name>.url).  However, it
> makes it harder for folks who just mirror/fork the superproject (and
> don't need to tweak the submodule), because they have to mirror/fork
> the submodule as well to support the relative URL (or edit
> submodule.<name>.url, which turns attempted mirrors into forks).
> Personally, I prefer relative URLs [1,2], but both external projects
> I've approached on this front have ended up with absolute URLs [3,4]
> ;).
> This is less of an issue for loosely-coupled submodules, since you'll
> can motivate your submodule changes to the submodule maintainers
> independent of the superproject (i.e. you can just say things like
> “I'm extending the API so I can iterate over widgets.  This lets you
> do things like frobbling whatsits in superproject” without having to
> present the associated superproject code).  Once you land the
> submodule changes upstream, your superproject branch will work without
> the need to tweak the URL (for absolute URLs) or publish a sibling
> mirror (for relative URLs).

Thanks, this is excellent information. Perhaps I should provide a
little more detail into what I'm doing. I know that having such
dependencies between superproject & submodule is bad and creates
complications like this, so maybe there is a different approach.

Right now our build system does not download third party dependencies.
We build on Windows & Android, so we maintain our own package binaries
& source code. Right now these are stored in 7zip files and checked
into the superproject. I was planning on creating a submodule for our
third party libs and store them extracted in there. That way, when we
switch branches, we don't have to delete & re-extract the third party
archives again (since between branches, libraries may change, be added
or removed). The submodule buys us an important thing, which is that
we won't have big binary blobs in our history. If we ever want to
remove them, all we're removing is a weak link to the submodule. The
binaries live with us forever since they're in history.

The only other thing I can think to do is incorporate logic into our
makefiles to copy down the 7zips from a permanent server, and we'd
adopt a naming format for the archives and download them based on that
information. This way, when we go back to an earlier tag, it will
always pull the correct version of the dependencies. We'd have to make
sure to never delete old libraries from the remote server or edit
existing ones.

I was exploring submodules to see if they would solve this problem.
However, because of the feature branch workflow, they do not seem
practical. I'm open to any other suggestions. Thanks!!
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to