Re: organizing multiple repositories with dependencies

[<dag@cray.com>]

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

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

For release tags, etc. I agree that this kind of mirrored tag/branch
behavior is the common case.

>> If you want the behavior you describe, a post-receive hook on the
>> component repositories is easy to implement.
>
> [1] Would such a post-receive hook be something that the user has to
> set up? Or would that be automatically set up after git clone?

The user/admin would have to set this up, at least for now.

> The main problem with the current submodule support is that there is
> so much manual work needed. It is too easy to forget a step. Moreover,
> it's not easy to determine *that* you forgot a step or which step you
> forgot.

I agree.  We can certainly make things more user-friendly.

>> Of course, this is entirely driven by git-subtree's model of actually
>> incorporating subproject history into one big umbrella repository.
>> There is no separation between the subprojects and umbrella projects.
>> It's one giant history.  Therefore, push/pull to/from subprojects are
>> explicit operations.  That's probably not the best model for every
>> situation but I find it very nice.
>
> I do not have enough (okay, any) experience with subtree to comment on
> that. The first part seems just what I want. I'm not sure about the
> explicit pushing/pulling part. That sounds too much like asking for
> the sort of problems that scared us away from submodules. Hopefully,
> I'm dead wrong. :-)

With subtrees, a topic branch in the umbrella project WILL be reflected
in the subproject because it is really one big repository.  It's a
little inconvenient to subtree push a new tag at the moment.  You have
to do a subtree split to a new branch and then push the branch to the
original component repository.  That's one thing I want to improve in
the short term.  I have found a need for then when creating release
tags.

But still, it seems odd to me that you'd create a topic branch in U and
then want to push it to a separate S repository.  Topic branches are by
nature ephemeral and I have never had a need to do something like that.
It just seems to go against the grain of what a topic branch is.  As I
said above, release tags and such are in a different category and that
is the main target of the subtree push enhancements I want to make.

>> But I don't agree
>> that we'll be able to design one model that works for everyone.  svn
>> externals are just one model to aggregate projects but it is not the
>> only one.  It just happens that no one working on Subversion bothered to
>> implement anything else.
>
> :-) I think I made it pretty clear that I was listing what *I* want.
> What *I* am looking for is something that is as invisible and
> automatic as possible.

Absolutely.

> That all sounds good. As long as the hooks are automatic (I'm hopeful
> you said "no" and "yes" to [1] above). If so, then I can promise you
> I'll be taking a look at subtree. :-)

I think at the very least we can provide setup scripts in contrib.  To
be honest I haven't thought deeply enough about this to determine if
there's a way to make it more convenient.

                                      -Dave