Re: Avery Pennarun's git-subtree?

[Avery Pennarun <apenwarr@gmail.com>]

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