Andy Parkins <andyparkins@xxxxxxxxx> wrote: > On Tuesday 2006 November 28 15:44, Shawn Pearce wrote: > > > So HEAD in a submodule is the current content of that submodule. > > Therefore any update-index call on a submodule should load HEAD > > (totally ignoring whatever branch it refers to) into the supermodule > > index. > > I was with you right up until here. > > Why should a submodule do anything to the supermodule? This is like saying, > when I edit a working tree file, it should automatically call update-index. > The supermodule index should only be updated in response to a manual > update-index (or commit -a I suppose). You misread my poorly written statement. :-) What I meant to say was that update-index run in the supermodule would load the submodule content into the supermodule index; much as an update-index on a file would load the content of that file into the index. > IMO, it should always be possible to take a submodule and work on it in > isolation - in an extreme case, by moving it out of the supermodule tree > entirely. Aside from sharing object directories, yes. > In summary, from the supermodule's point of view: > * A submodule with changed working directory is "dirty-wd" > * A submodule with changed index is "dirty-idx" from the supermodule's > * A submodule with changed HEAD (since the last supermodule commit) > is "changed but not updated" and can hence be "update-index"ed into the > supermodule > * A submodule with changed HEAD that has been added to the supermodule index > is "updated but not checked in" > * A submodule with changed HEAD (since the last supermodule update-index) is > both "changed but not updated" _and_ "updated but not checked in", just > like any normal file. > > What's needed then: > * A way of telling git to treat a particular directory as a submodule instead > of a directory > * git-status gets knowledge of how to check for "dirty" submodules > * git-commit-tree learns about how to store "submodule" object types in > trees. The submodule object type will be nothing more than the hash of the > current HEAD commit. (This might be my ignorance, perhaps it's just > update-index that needs to know this) Err, uhm, more like git-write-tree. git-commit-tree doesn't care about the tree content. And all of the tree reading code. And all object traversal code (e.g. rev-list --objects). Martin Waitz's submodule prototype has been working on those details. Its non-trivial due to the number of locations affected. > In my head, it would look something like this: > > $ mkdir supermodule; cd supermodule > $ git init-db > $ git clone proto://host/submodule.git > $ git add --submodule submodule > $ git update-index submodule > $ git commit -m "Added submodule to supermodule" > [ edit submodule ] > $ git status > submodule is dirty, the working directory has changed > [ update-index in submodule ] > $ git status > submodule is dirty, the index has changed > [ commit in submodule ] > $ git status > submodule is changed but not updated > $ git update-index submodule > $ git status > submodule is updated but not checked in > $ git commit -m "Record submodule change in supermodule" Yes, exactly my thoughts on the matter. > Am I crazy? Maybe, but I'm not a shrink. Your email looked sane. :-) -- 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