Re: Subtree with submodule inside?

From: Robert Dailey <rcdailey.lists@gmail.com>
Date: Aug 6, 2014, 18:18 UTC
Message-ID: <CAHd499AmY+EYXAK8h_oYiOn-amnNrE1+a7qsQ4x7bCOVsJDxcw@mail.gmail.com>
In-Reply-To: <xmqqk36lmrpl.fsf@gitster.dls.corp.google.com>

On Wed, Aug 6, 2014 at 12:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

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