Re: Avery Pennarun's git-subtree?

[Bryan Larsen <bryan.larsen@gmail.com>]

On 10-07-26 12:41 PM, Linus Torvalds wrote:
> 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