On Fri, Jul 23, 2010 at 11:10 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html