Am 06.08.2014 um 20:18 schrieb Robert Dailey: > On Wed, Aug 6, 2014 at 12:51 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> My knee-jerk reaction would be "subtree would break submodules >> badly, don't use it" ;-). >> >> After all, I invented subtree merge as an ugly interim workaround >> before submodule subsystem got into a usable shape, hoping that new >> projects can use submodules without resorting to subtree merges. > > (Sorry Junio, I forgot to "Reply all" and accidentally sent this only > to you. Resending to group) > > Hi Junio. I agree it certainly does sound evil and defeats the purpose > of the goal of ultimately creating a simple workflow :) > > Could you go over how you feel the submodule system got into "usable" > shape? It still seems to still have all of the problems I still hate: > > * If you branch a production branch to implement a feature that also > impacts the submodule, you need to branch the submodule. There is no > easy interface for this and rather clumbsy, especially if people are > using GUI tools like SourceTree (most of the people on my team are). There were thoughts about having "git branch" optionally create a branch in the submodule too. But in a lot of real world scenarios that won't help because the same branch name won't necessarily make sense in superproject and submodule at the same time, so you'd have to create different branches anyway. But if it makes a significant amount of users happy, I think adding --recurse-submodules to "git branch" might make sense to make life easier for them. I do not know SourceTree myself, but do you have any ideas you'd like to share how you could envision to make branching less tedious? I hope it at least shows you that there are modifications inside the submodule while examining the superproject and provides an easy way to start a new instance inside the submodule to commit the changes there? Otherwise it'd make life unnecessarily hard for you. > * Pull requests do not include submodule changes in the review (we use > Atlassian Stash). So 1 pull request per submodule has to be performed > and they have to be merged in the appropriate order. Which seems to be a chore in your scenario, but is just the Right Thing to do when someone else maintains the submodule. Given the danger of a rebase in the submodule pulling away the commit recorded in the superproject it is considered best practice to always merge in the submodule into a never-to-be-rebased branch first before committing the superproject. But I agree it is twice the work. > * Submodules complicate an otherwise beautiful workflow that Git is > supposed to provide (branching) in many ways, and also there are > restrictions on the order in which you modify parent repository vs > submodule. I cannot remember anyone coming up with a better workflow when having distinct repos (superproject and submodule). Subtree on the other hand has other issues (like you can easily forget to push a fix to a subtree to its upstream, which is something submodules make you aware of). And the submodule workflow is as beautiful as ever if you consider superproject and submodule different repos (which they are), and then it is obvious that you have to do everything twice ;-) But I do have the impression that a lot of third party tools are still rather submodule ignorant and of not much help there. > If I'm going to put my common code in a separate module for the > purposes of splitting apart projects that depend on the common code, I > want the workflows that Git provides to remain simple. Subtrees seem > to do that, you just sync with the common repo every now and then. If you are only interested in single "from upstream into my repo" workflow and don't care much about pushing your local changes back to the common code repo, subtrees are easier to use than submodules. But if you need or want to contribute your changes back, I believe submodules gain the upper hand rather quickly. But back to your original question: I do no see a way to import another repo using a submodule via subtree either. You'd have to consistently use submodules to make that work (even if that means that you'll have three repos to think about, one being embedded in the other). -- 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