Re: Avery Pennarun's git-subtree?

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jul 23, 2010, 17:11 UTC
Message-ID: <4C49CD49.4010101@web.de>
In-Reply-To: <4C49BDB7.3080805@gmail.com>

Am 23.07.2010 18:05, schrieb Bryan Larsen:

Show 10 quoted lines

> On 10-07-23 11:10 AM, Jens Lehmann wrote:
>> That is just one example. Another one is code shared between
>> different repos (think: libraries) where you want to make sure that
>> a bugfix in the library made in project A will make it to the shared
>> code repo and thus doesn't have to be fixed again by projects B to X.
>> This was one of the reasons we preferred submodules over subtrees
>> in our evaluation, because there is no incentive to push fixes inside
>> the subtree back to its own repo like there is when using submodules.
> 
> But you stated above that each project has its own fork of the library.   So there's no special incentive to push changes from the fork back to its master repo.

When you are not working on your own, it is preferable to be able to get changes upstream into a submodules repo to share them. So if you can do that (either via push or patches sent by email or whatever), then use it's URL directly (and then you have the incentive that fixes get pushed, which is nice). Or you can't, then use a fork reachable by the people you work with (then you still can see all fixes made by your group in the forked repo and can decide to push them upstream). Then pushing fixes back to the original repo is a matter of courtesy, as it is with every other work flow I know. And I think that is just the same thing we all do with plain git repos when working with others: If you can push, you use it directly to clone from, if you can't, you fork it.

Show 8 quoted lines

> In my experience, it's possible to make it usable if and only if:
> 
> 1.  you have a small team
> 2.  all of whom are very comfortable with git
> 3.  changes inside submodules are either infrequent or only happen in a single direction
> 4.  the project is not public/open source
>
> I think #4 is the killer reason why submodules don't work.  It works fine if the submodule is fairly independent, but if you have a patch to the submodule that was created for and in the context of the superproject, things get really annoying really quickly.

What is the problem with the "forked repo" solution for #4?