Re: Avery Pennarun's git-subtree?

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 23, 2010, 22:32 UTC
Message-ID: <AANLkTimSoe9iqu4cJCH1d4rVsWHpFn3+8pbrCxsnVM1D@mail.gmail.com>
In-Reply-To: <4C49B0E9.1090300@web.de>

On Fri, Jul 23, 2010 at 11:10 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:

Show 12 quoted lines

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

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

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.

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

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.

Show 11 quoted lines

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

Show 8 quoted lines

> 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