Yann Dirson <ydirson@xxxxxxxxxx> 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. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html