Re: RFC: Subprojects

From: Junio C Hamano <junkio@cox.net>
Date: Jan 18, 2006, 18:49 UTC
Message-ID: <7v4q41wevw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0601181214150.25300@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> I assume these get updated by checkout when you check out the commit with 
> them as bind lines?

I did not think of that when I wrote that message, but you are right.

> Ah, okay, so it's cheating for checkout, because checkout is supposed to 
> understand everything, but not cheating for other things.

Yeah; to put it another way, read-tree of the toplevel tree and checking it out is equivalent to do the skelton read-tree followed by --prefix read-tree of all the bound projects, so checkout can optimize.

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

> Shouldn't "git read-tree --prefix=linux-2.6/ -u kernel" remove everything 
> else in the index in linux-2.6 itself, making the "git update-index 
> --force-remove" unnecessary?

I agree that "-u" should imply that. The current "read-tree --prefix=linux-2.6/" in proposed updates refuses if linux-2.6/ appears in the original index.

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

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.