Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html