Re: Avery Pennarun's git-subtree?

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jul 23, 2010, 15:10 UTC
Message-ID: <4C49B0E9.1090300@web.de>
In-Reply-To: <AANLkTimOb2VjYI21wQsC64lm4HsVPwpRWd1twIUBnbJ3@mail.gmail.com>

Am 22.07.2010 21:41, schrieb Avery Pennarun:

Show 15 quoted lines

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

Show 5 quoted lines

> Surely including *repository URLs* inside the *repository content* is
> at least as bad as including branch names.  If we're going to do one,
> we might as well do the other.  But it won't help, because the stored
> branch name will probably be 'master', and my personal hacked-up copy
> of gem13 shouldn't be on a branch named master anyway.

You sure are aware that having a branch name associated with a submodule checkout is a request repeatedly made?

Show 6 quoted lines

> The *real* need for submodules - the need you can't fix without
> submodules - has nothing to do with these requirements.  It's about
> each submodule wanting to have its own lifecycle, owner, changelog,
> and release process, and - perhaps this is actually the killer
> requirement - each supermodule wanting to be able to cleanly rewind a
> submodule if they don't like the new version.

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.

Show 7 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? ;-)

>> rebase and merge needs separate    | rebase and merge works normally
>> work in submodule currently        |
> 
> True.

Nope, there is a patch in pu doing that when it is a simple fast forward and giving you advice when both sides are already merged inside the submodule (CCed Heiko, because he is the author of that feature)

It is the /commits/ that have to be done twice, once in the submodule and then in the superproject. (But that is not necessarily bad, imagine having git gui as a submodule: you would be automagically reminded that stuff for git gui should be sent somewhere else than to Junio).