Re: Avery Pennarun's git-subtree?

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

On 10-07-23 01:11 PM, Jens Lehmann wrote:
> Am 23.07.2010 18:05, schrieb Bryan Larsen:
>> 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.

So basically you're saying: sometimes you can use a non-forked 
repository, which has a whole bunch of disadvantages, but has the minor 
advantage that you're "forced" to push your changes upstream.

Which I see as a disadvantage because that means you're pushing untested 
changes.

Or else you use a forked repo, which is basically the same as using 
git-subtree, except for a lot of additional admin hassle.

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

Please tell me how I can set up a public project on github where project 
A contains module X, so that Joe Average User can clone A, make a change 
in the module X and send a simple pull request to get that change into 
A.   The change is one that's inappropriate to push upstream to X 
without additional work, but is appropriate for A at this point in time. 
  Joe's a beginning git user.

That's actually a simple use case compared to others I've run into.

Bryan