Re: [RFC] Submodules in GIT

From: Yann Dirson <ydirson@altern.org>
Date: Nov 21, 2006, 23:54 UTC
Message-ID: <20061121235429.GH5443@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <Pine.LNX.4.64.0611211437430.3338@woody.osdl.org>

On Tue, Nov 21, 2006 at 02:51:56PM -0800, Linus Torvalds wrote:

Show 11 quoted lines

> 
> 
> On Tue, 21 Nov 2006, Yann Dirson wrote:
> > 
> > I'm not sure I get the reason why the submodule should not be recorded
> > on "commit level".
> 
> Because that would be STUPID.
> 
> What does the submodules have to do with the commit level? Nothing. Nada. 
> Zero.

Oh, I see I may have expressed something in the wrong way :) Namely, I brought an idea coming from partial merges into a discussion on submodules, because when thinking about the former, I realized we could maybe use similar mechanisms for both.

Note that the proposal I outlined did not break the tree, in that the sumodule tree is still in the same place. In the case of a partial merge, the info that a subtree has been merged in this commit is indeeed part of the commit itself.

I agree that the subtree case is somewhat different, and my idea may not apply to submodules after all :)

A question would be, do "submodules" have to be permanent objects ? I suppose it depends on what people want to use them for. Indeed, the "submodule" names strongly carries the idea of a permanent subset of the repository. My proposal partial merges could be seen as using transient submodules: they do not matter much during most of the repo life.

Put it another way, I see the proposal of allowing tree entries to be commits in addition to trees and blobs, akin to recording the submodule _history_ inside the _tree_, which I feel precisely violates the distinction you want to keep between those 2 concepts.

> And a sub-project simply doesn't even _do_ that. Much of the time, a 
> subproject stays constant, and is not something that comes and goes on an 
> individual commit basis.

What about the case of a subproject that would evolve fast, and for which we may not want intermediate versions to be part of the supermodule ? (just exploring an idea without real connection to the one discussed above)

I mean, I have a tree in which the whole software for an embedded platform is stored, including kernel, apps, etc. While working on the kernel, I may want to do several commits to that submodule, and may not want to commit to the supermodule for each kernel commit, only when I feel the kernel is stable enough.

One may argue I just have to use a branch. Anyway, there will be a need for submodule-specific branches - eg. kernel.org ones in my case.

An alternative would be to allow committing to the submodule without creating matching supermodule commits, and let the user decide when he wants to commit at the higher level. That way, 2 successive supermodule commits could have non-successive "subcommits".

Best regards,