On 17 April 2012 13:51, <dag@xxxxxxxx> wrote: > Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> writes: > >> If you work on a subproject (in its own repo) then a subsequent pull >> in the umbrella project should bring this new code into the umbrella >> project (assuming that would make sense given the branches involved). > > I don't necessarily think this is always what should happen. I can't > comment on git-submodule since I haven't used it in its more recent > incarnation, but one thing I like about git-subtree is that it's > explicit. I have to do a "git subtree pull" on the umbrella project to > pull in the new changes from a subproject. That gives me some degree of > control over when to update sources. I suspect one can do the same by > using "git pull" in submodule directories. 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. Any changes in S's topic should show up in U's topic (probably after some sort of update command like git fetch/pull). This should be unusual, though, you should be working in U, not S. If you want to work on something in S that you don't want to see in U, then you should not be working in S's topic. > If you want the behavior you describe, a post-receive hook on the > component repositories is easy to implement. I just did that a couple > of weeks ago for a subtree-aggregated repository. When a component > receives something it immediately does a "git subtree pull" on a > workarea on the server and then does a push from that workarea to the > subtree-aggregated repository. [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 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. > 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. :-) >> After rereading my earlier reply I felt that it might be interpreted >> as being disparaging of submodules/subtree/gitslave. > > I didn't interpret it that way at all. I agree with you that > subproject/superproject support could be much better. Good. I just wanted to be extra clear because you (and others) are working on something that is very important to me. The last thing I want to do is discourage you. :-) > 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. (I find working with Git really quite enjoyable but it has a very steep learning curve. E.g., I have (literally) spent hours explaining rebase and merge to our new developers. Surprisingly, some come from college/university without having ever used an SCM tool but even for those that have learning Git is quite a challenge. And Git's API isn't always particularly helpful. The "checkout" command is a perfect (bad) example in that regard. Even those that haven't used SVN/CVS before do not associate "checkout" with switching branches. And using git checkout to go back to the HEAD version of a file you've changed? Sure, it can be explained and learned but it doesn't make automatic sense. What does switching branches have to do with undoing changes? [Yes, it makes sense given Git's implementation but *not* from the user's point of view.] Given that, I really do *not* want to pile on more just to accommodate subprojects.) > Perhaps a good way to go would be to provide the basic operations (I > think we have most of that) and some hooks in contrib/ or elsewere to > implement various models. Just like git imposes no particular workflow > model I don't think git should impose one particular aggregation model. > What we do need is better documentation of what the various models and > tools are. For example, I would find a subtree/submodule comparison > highly valuable. It would help people decide which model is best for > them. 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. :-) -- 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