Re: Avery Pennarun's git-subtree?

[Avery Pennarun <apenwarr@gmail.com>]

On Mon, Jul 26, 2010 at 10:56:58AM +0200, Jakub Narebski wrote:
> On Sat, Jul 24, 2010, skillzero@gmail.com napisał:
> > git-submodule might be technically possible in this situation, but
> > having to commit and push each submodule and then commit and push the
> > super module makes it slightly worse than just dealing with the
> > space/download/performance issues of one huge repository.
> 
> But this is just a matter for improving UI for dealing with submodules,
> isn't it.   For example having "git commit --recursive" would help
> with 'having to commit each submodule', though how you would write commit
> messages then: perhaps supermodule commit message could be by default
> composed out of submodules commits (if any).  "git push --recursive"
> (or some support for push in "git remote") would help with 'having to
> push each submodule'.

For "recursive" commit, for my own workflow, I would rather have it work
like this: from the toplevel, I can 'git commit' any set of files, as long
as they all fall inside a particular submodule.  That is, if I do

	git commit mod1/*.c mod2/*.c
	
it should reject it (with a helpful message), because the commit would cross
submodule boundaries.  But if I do

	git commit mod1/*.c
	
I think it should create a new commit in mod1, leave my superproject
pointing at that new commit, and stop (ie. without the superproject having
committed the new commit pointer).

Why?  Because my normal workflow is:

  - make a bunch of superproject/submodule changes until they work.
  - commit the submodule changes with a submodule-relevant message
  - commit the superproject change with a supermodule-relevant message
  
I wouldn't want to share commit messages between the two, so actually having
a single commit process be "recursive" would not do me any good.

However, pushing is a separate issue entirely.  Having push be recursive
would be easy, but it doesn't solve the *real* problem with pushing: git
doesn't know what branch to push to in the submodule, and the submodule most
likely isn't pointing at a pushable repo at all, even if the supermodule is. 
This is why I keep coming back to the idea that I really want to push all
the submodule objects into the superproject's repo.

Have fun,

Avery