Re: Avery Pennarun's git-subtree?

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Jul 23, 2010 at 11:10 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> 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.

Now all your fellow developers have to push their submodule code to a
single upstream repo?  That's rather centralized and un-git-like.

For the rest, Brian Larsen answered this one well, and I agree with him.

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

Of course it is; I requested it myself.  Then, two years later after
thinking about the problem a lot and writing git-subtree out of
frustration, I realized that even if this feature existed, it wouldn't
help at all.

If you use git-submodule, you must push your submodule commits
separately or the supermodule is broken for everybody but you.  To
push a submodule, you need a) an upstream to push to and b) a branch
name.  It's easy to forget to create a branch name, so of course
people request that feature.

However, the real problem is "you must push your submodule commits
separately."  Fix that, and I can guarantee that the request for
submodule branch naming will disappear.

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

I think you'd like svn; it's pretty cool.  All changes made to a
project need to get pushed to a central upstream repo so you never
forget to share them.

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

Fast forwards are not merges, and pu is not now.

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

Yup, I agree that requiring a separate commit to the submodule repo is
not a bad idea.  I always do this anyway even when using git-subtree,
because I'm thinking ahead to the day when I'll push my submodule
changes upstream and I want my commit message to make sense.  But
that's because I think ahead like that.  Having the tool force me to
do it would be harmless and help people avoid mistakes.

The syntax for it ought to be nice though.  I should be able to do:

    git commit -- path/to/submodule

And have it commit everything in the submodule tree as a new commit in
the submodule.  I don't want to have to think about cd'ing to
path/to/submodule just so I can commit the files I changed in there.

Have fun,

Avery