Re: [RFC] Submodules in GIT

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 22, 2006, 03:40 UTC
Message-ID: <20061122034056.GB23856@spearce.org>
In-Reply-To: <20061121235429.GH5443@nan92-1-81-57-214-146.fbx.proxad.net>

Yann Dirson <ydirson@altern.org> wrote:

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

No.  Linus is right.  Submodule commits belong in the tree.

We want to record a specific subtree within a larger tree. There are three ways we can refer to a tree: by its tree SHA1, by a commit which points at the tree SHA1, or by a tag which points at a commit which points at the tree SHA1, or by a tag which points at a tag which points at a commit which points at a tree SHA1. Which is basically a tree-ish.

The advantage of linking to the commit-ish (commit or tag) and
not the tree-ish for a submodule is that it also provides you quick
access to answer the "how did this tree arive at this state" question
as the answer cannot come solely from the top level commit chain.
The reason... keep reading...

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

Right. The submodule is free to be committed to an infinite number of times for any given commit in the supermodule.

It is expected that users will commit to a submodule say hundreds of times for every commit they make to the supermodule. Or thousands. This is especially true if the submodule is some very large project, e.g. the Linux kernel, and the supermodule "upgrades" the kernel it is using after 3 months of staying on the same version. Suddenly the supermodule has only 1 commit which covers maybe 10,000 commits in the submodule.

Yet we still want to be able to efficiently perform operations like "git bisect" within the scope of that submodule, to help narrow down a particular bug that is within that submodule. To do that we need the commit chain (all 10,000 of those commits) in the submodule. To get those we really need a commit-ish and not a tree-ish, as going from a tree-ish to a commit-ish is not only not unique but is also pretty infeasible to do (you need to scan *every* commit).