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). * 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. * 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. 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. -- 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