From: <dag@cray•com>
To: Hilco Wijbenga <hilco.wijbenga@gmail•com>
Cc: Git Users <git@vger•kernel.org>
Subject: Re: organizing multiple repositories with dependencies
Date: Tue, 24 Apr 2012 12:17:12 -0500 [thread overview]
Message-ID: <nnghaw93v8n.fsf@transit.us.cray.com> (raw)
In-Reply-To: <CAE1pOi38krwXZuiYxtpLwm92N=NvWkP30V_=6cnHw=sdyk6QhA@mail.gmail.com> (Hilco Wijbenga's message of "Tue, 17 Apr 2012 14:43:37 -0700")
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
next prev parent reply other threads:[~2012-04-24 17:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 9:27 organizing multiple repositories with dependencies Namit Bhalla
2012-04-16 14:30 ` Jakub Narebski
2012-04-16 20:08 ` dag
2012-04-17 17:29 ` Hilco Wijbenga
2012-04-17 17:51 ` dag
2012-04-17 18:37 ` Seth Robertson
2012-04-17 19:55 ` Hilco Wijbenga
2012-04-17 20:51 ` dag
2012-04-17 21:43 ` Hilco Wijbenga
2012-04-17 22:25 ` PJ Weisberg
2012-04-17 22:49 ` Hilco Wijbenga
2012-04-18 10:15 ` Namit Bhalla
2012-04-18 12:09 ` Jens Lehmann
2012-04-24 17:17 ` dag [this message]
2012-04-24 18:54 ` Hilco Wijbenga
2012-04-24 21:09 ` PJ Weisberg
2012-04-24 22:04 ` Hilco Wijbenga
2012-04-24 23:33 ` dag
2012-04-30 19:25 ` Phil Hord
2012-04-30 19:43 ` dag
2012-04-18 12:19 ` Jens Lehmann
2012-04-24 17:22 ` dag
2012-04-24 17:59 ` Seth Robertson
2012-04-24 20:26 ` Jens Lehmann
2012-04-24 20:52 ` Seth Robertson
2012-04-24 23:21 ` dag
2012-04-28 17:31 ` username localhost
2012-04-24 23:25 ` dag
2012-04-25 12:48 ` Seth Robertson
2012-04-27 14:23 ` dag
2012-04-24 19:48 ` Eugene Sajine
2012-04-24 22:11 ` Hilco Wijbenga
2012-04-24 23:38 ` dag
2012-04-24 23:36 ` dag
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nnghaw93v8n.fsf@transit.us.cray.com \
--to=dag@cray$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=hilco.wijbenga@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox