Re: RFC: Subprojects

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 18, 2006, 19:29 UTC
Message-ID: <Pine.LNX.4.64.0601181359400.25300@iabervon.org>
In-Reply-To: <7v4q41wevw.fsf@assigned-by-dhcp.cox.net>

On Wed, 18 Jan 2006, Junio C Hamano wrote:

Show 11 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > ... I thought we 
> > decided that the stuff that doesn't know about subprojects sees them as 
> > opaque, rather than as their contents, so your toplevel git diff doesn't 
> > show you a millions lines when you switch from linux-2.6.14 to 15.
> 
> It was discussed in the context of "gitlink" approach as a way
> to keep things simple.  In the "bind" approach, I am doing
> things a bit differently, and this "toplevel has everything" is
> one big difference.

I thought that had been a question of what is best as an interface, but either is plausible.

Show 11 quoted lines

> > I thought we decided that committing the superproject wouldn't
> > commit the subprojects.
> 
> I see it as a policy.  We can forbid the modification of the
> subproject part of the index (i.e. detect and refuse to commit
> and/or do "git reset --mixed" only for the subproject part) so
> that the commit outlined in the "bind" approach does not _have_
> to make a new commit, if you want to work that way.  But if
> somebody else wants to make a related set of changes to the
> superproject and bound subprojects, we _could_ allow a commit
> per subproject.

I think it makes most sense, for the purpose of consolidating code paths, if the superproject may only be committed with clean subprojects; the porcelain has the option of responding to unclean subprojects by committing them to make them clean, and then there is only a single case for how the superproject commit happens. I think it makes most sense as a command line option, like -a is; if you want to commit dirty suprojects, you use --subprojects, and it does that. If you're not expecting to need it, you won't start doing the wrong commit.

Show 12 quoted lines

> > I hope people will want to prepare their commits to the kernel subproject 
> > as would be suitable for pushing to Linus, which would suggest that they'd 
> > tend to do a commit in the kernel subproject embedded in their 
> > superproject separately from doing the commit in the superproject, and 
> > so the branch head would match the index but not the bind line when they 
> > got to committing the superproject.
> 
> Yes, that is the workflow I outlined in the footnote part you
> did not quote.  I think it is cleaner to do things that way: to
> have a separate, kernel-only repository+worktree and do pure
> kernel work there, and fetch into the superproject branch that
> keeps track of the kernel subproject in that superproject.

I actually meant that I expected people to go into superproject/linux-2.6, make changes, and commit there, using the place it appears in their superproject working tree as a working tree for the subproject, so the opposite of your footnote, but still doing the subproject commit as a step before the superproject commit.

For example, they might want to send the subproject changes upstream as a patch, get feedback, reset the subproject, do revised changes, commit that, get it merged upstream, and then commit the changes to the superproject, including in the message the fact that the changes have been pushed upstream. But they may still want to do this all within the working tree of the superproject, so that they can test their changes in context.

Show 21 quoted lines

> Having more than one working tree with .git/, everything except
> HEAD and index undef which are symlinked to one copy, like you
> do, would be a natural way to work.
> 
> 	embed/.git/HEAD -> refs/heads/master
> 
> 	embed/linux-2.6/.git/HEAD -> refs/heads/kernel
> 	embed/linux-2.6/.git/refs -> ../.git/refs
> 	embed/linux-2.6/.git/objects -> ../.git/objects
> 
> Then, after hacking on the collective whole to make the whole
> thing work in "embed" directory, you would:
> 
> 	$ cd linux-2.6
>         $ git commit
> 
> to make commit that can be sent Linus, at the same time updating
> the "kernel" branch.  Then come back to the toplevel, tell git
> that you updated the "kernel" branch so it does not complain
> that the "bind" in the HEAD commit does not match "kernel" head,
> and make a toplevel commit.

I'm not sure having a .git directory for a subproject inside a subdirectory of the superproejct's working tree is all that good an idea, and I don't think it should be necessary in any case, because the toplevel index has all the information from the subproject index. The only think would be having "git commit" notice what you're doing when you run it from a directory that's a subproject.

	-Daniel
*This .sig left intentionally blank*