On Sun, Jul 25, 2010 at 09:57:55PM +0200, Jens Lehmann wrote: > Am 24.07.2010 00:32, schrieb Avery Pennarun: > > 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. > > But isn't that exactly the same thing you would have to do for your > superproject too to be able to push your changes for your fellows? No. On github, only I can push to my superproject's history, and yet everyone can still pull from me. With what you're proposing, for all my submodules, we can't each have our own project; we all have to push to the shared one. (Just to be clear: I don't want to fork *every submodule by hand every time*. I just want *my* stuff to be in *my* repo. The easiest way to do this would be to have all my changes in a single repo, ie. my fork of the superproject.) > >> 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. > > And submodules force you to do that. Yes. This is a limitation of submodules, but not one that bothers me. And it encourages good behaviour. > > 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. > > Yes, that would be a nice feature (assuming you have a branch in the > submodule to commit these changes to ;-). No, I explicitly *don't* want to have to have a branch in the submodule; that's too much extra thinking at that stage. 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