Re: Avery Pennarun's git-subtree?

From: Bryan Larsen <bryan.larsen@gmail.com>
Date: Jul 26, 2010, 17:36 UTC
Message-ID: <4C4DC799.6070702@gmail.com>
In-Reply-To: <AANLkTimQywtn-0Fcr-ceLeHGeSBNROt+T=K+TowF_u5h@mail.gmail.com>

On 10-07-26 12:41 PM, Linus Torvalds wrote:

Show 22 quoted lines

> On Mon, Jul 26, 2010 at 9:37 AM, Marc Branchaud<marcnarc@xiplink.com>  wrote:
>>
>> I think I should mention one aspect of what we're doing, which is that a lot
>> of our submodules are based on external code, and that we occasionally need
>> to modify or customize some of that code.  So it's quite nice for us to
>> maintain private git mirrors of the external repos, with our own private
>> branches that contain our modifications.  Although we want to get much of our
>> changes incorporated into the upstream code bases, upstream release cycles
>> are rarely in sync with ours.
>
> THIS.
>
> This is why I always thought that submodules absolutely have to be
> commits, not trees. It's why the git submodule data structures are
> done the way they are. Anything that makes the submodule just a tree
> is fundamentally broken, I think.
>
> That said, I'm not competent to comment on the actual user interface
> issues. I can well believe that git-subtree has a nicer interface.
>
>               Linus
>

To me, that's what git-subtree is: an internal private mirror of an external repo. Using git submodule moves that into a separately managed repo, which is just unnecessary hassle. Why maintain repo called "clone of library X for project A" when you can just stick it inside of project A without any downsides?

For us, changes are made in the superproject and tested in the superproject. Once they're tested, a git subtree push or a git subtree split pushes the patches to the subproject. Once the subproject has accepted the patches, a git subtree pull merges them. Same workflow as the "private git mirror of external repo" listed above, just without the hassle of having another repo to manage.

Bryan