Re: RFC: Subprojects

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 11, 2006, 20:06 UTC
Message-ID: <Pine.LNX.4.64.0601111157020.5073@g5.osdl.org>
In-Reply-To: <43C55FEF.2090108@hogyros.de>

On Wed, 11 Jan 2006, Simon Richter wrote:

Show 5 quoted lines

> 
> Exactly. The questions I posed in the last paragraph of the initial mail,
> rewritten for clarity, would be
>  - "should cg-commit automatically create a commit in the master project when
> a change in the subproject is committed?", and

No.

Don't commit in the "parent" thing automatically. The sub-project should be as independent as possible, and you should see a commit to that to be nothing more than "editing" a regular file in the top-level project.

In many ways, if you decide to look into doing a "gitlink" kind of object, that object really _does_ conceptually point to the .git/HEAD file in the subproject. So when you do a commit in the subproject, conceptually that is no different from editing the .git/HEAD.

Then, when you want to commit the _dependency_ of the top-level project on the sub-project, you commit in the top level. That commit probably does other things too: it probably also commits the code in the top level that now depends on the sub-project changes.

So don't tie the two together any more than necessary. My suggested usage case has the big advantage that the sub-project is much less tightly coupled, so you can do things like "git pull" _inside_ the subproject, to update it, and then do a big compile in the top-level project to reflect the changes (and perhaps update stuff at the top level to conform to changes in the sub-project), and then commit in the top independently (which will now automatically pick up the changes to .git/HEAD that "git pull" did on the subproject).

>  - "should cg-commit automatically commit all changes to subprojects when a
> path that has been listed on the command line contains a subproject?".

Again, I'd really suggest not. If you keep the "gitlink" really meaning the ".git/HEAD" contents of the subproject (which is a good semantic rule), then if there is any dirty state in the sub-project, it is totally irrelevant to a "git commit". Because it's dirty, it's not part of of .git/HEAD yet.

Now, obviously you should make "git status" _talk_ about the fact that the sub-project is dirty, so that the committer sees that the sub-project needs committing first (the same way "git status" now informs git commit about dirty files that haven't been updated).

(I'm saying "git" here all the time rather than cg-, because not only don't I know cogito very well, I think you want to do most of the core at the git level, and just teach cg about the new capability).

			Linus