Re: organizing multiple repositories with dependencies
- From
- dag@cray.com <dag@cray.com>
- Date
- Apr 24, 2012, 17:17 UTC
- Message-ID
- <nnghaw93v8n.fsf@transit.us.cray.com>
- In-Reply-To
- <CAE1pOi38krwXZuiYxtpLwm92N=NvWkP30V_=6cnHw=sdyk6QhA@mail.gmail.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.
Show 5 quoted lines
>> 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.
Show 12 quoted lines
>> 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.
Show 9 quoted lines
>> 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