Re: Avery Pennarun's git-subtree?

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 28, 2010, 18:32 UTC
Message-ID: <201007282032.42106.jnareb@gmail.com>
In-Reply-To: <20100727183658.GB25124@worldvisions.ca>

On Tue, Jul 27, 2010, Avery Pennarun wrote:

Show 39 quoted lines

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

I think it is quite good idea, but it covers only one of the three most
common (I think) used versions of git-commit:
 * git commit <files>        # your proposal covers this
 * git commit -a             # but I think either this
 * git commit                # or this is actually more common

Also "git commit ." in a submodule cannot be done in this proposal, because it is indistinguishable from "git commit <submodule>" committing state of submodule in supermodule.

Perhaps it would be matter of porting "--relative=<path>" or adding "--submodule=<name>" option to git-commit?

Show 6 quoted lines

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

I think there should be two easy to obtain variants of recursive clone:

1. Current one, where each submodule gets its own repository in the place
   it is checked out in working area (in worktree) of supermodule.

2. New one, where submodule repositories are in .git/submodules/<name>
   in supermodule GIT_DIR, and submodules use gitfiles (probably with
   some notation that path is relative to supermodule, like e.g. //<path>
   or .../<path>).

I'm not sure though how it would translate into pushing...

-- 
Jakub Narebski
Poland