Re: Avery Pennarun's git-subtree?

From: Bryan Larsen <bryan.larsen@gmail.com>
Date: Jul 23, 2010, 16:05 UTC
Message-ID: <4C49BDB7.3080805@gmail.com>
In-Reply-To: <4C49B0E9.1090300@web.de>

On 10-07-23 11:10 AM, Jens Lehmann wrote:

Show 29 quoted lines

> Am 22.07.2010 21:41, schrieb Avery Pennarun:
>> I create an app named myapp on github:
>>
>>     git://github.com/apenwarr/myapp
>>
>> It uses 17 different ruby gems, which I import as subprojects.  I have
>> two choices:
>>
>> [1] .gitmodules can use absolute paths to the original gem locations:
>>
>>     git://github.com/rubygems/gem[1..n]
>>
>> [2] Or else I can fork them all and use relative paths in .gitmodules:
>>
>>     ../gem[1..n]
>>     translates to -->  git://github.com/apenwarr/gem[1..n]
>
> You forgot what we do as best practice at work:
>
> [3] Fork the gem repos on github (or another server reachable by your
>      co-workers) and use those, so you don't have to change the URL
>      later:
>
>      git://github.com/apenwarrrubygems/gem[1..n]
>
> Your problems go away, setup has to be done only once on project
> start and not for every developer, you can use your own branchnames
> and you have a staging repo from where you can push patches upstream
> if necessary.

What's best practice for open source projects? I do this, but nobody except my coworkers can push to my forks, so it's a huge rigamarole just to get a fix into a submodule.

Show 8 quoted lines

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

Show 13 quoted lines

>
>
>>>> It's very clear that git-submodule's current behaviour totally
>>>> mismatches the entire git philosophy.  That's why it's so impossible
>>>> to make the git-submodule command usable.
>>>
>>> That's very strong accusation.
>>
>> Agreed... but that doesn't make it wrong :)
>
> But calling a feature "impossible to make ... usable" is an
> interesting thing to say about a feature lots of people are
> using productively in their daily work, no? ;-)

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.

Bryan