From: Shawn Pearce Date: Sat, 25 Nov 2006 06:53:38 GMT Subject: Re: [RFC] Submodules in GIT Message-ID: <20061125065338.GC4528@spearce.org> In-Reply-To: <20061123232313.GB24909@nan92-1-81-57-214-146.fbx.proxad.net> Yann Dirson wrote: > On Tue, Nov 21, 2006 at 10:40:56PM -0500, Shawn Pearce wrote: > > 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). > > We don't need to have commits in the tree for this. We'll just have > submodule commits which are not attached to a supermodule commit, and we > can access the whole submodule history through the submodule .git/HEAD, > just like we do for a standard git project. No. You cannot do that. How do we setup .git/HEAD when bisecting the supermodule? Or merging it? Or doing anything else with it? Ideally the .git/HEAD of every submodule should seek to the commit that points at the tree of the submodule which the supermodule is referencing. This lets you then perform a bisect within the submodule when you identify the supermodule commit which caused the breakage. We need the submodule commits to do this. Doing it without is too expensive. --