hoi :)
On Tue, Nov 28, 2006 at 04:29:05PM +0000, Andy Parkins wrote:
> 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.
when tracking refs/heads/master instead of HEAD, you also get:
* A submodule where HEAD is not pointing to refs/heads/master is
"dirty-branch" or something.
> What's needed then:
> * A way of telling git to treat a particular directory as a submodule instead
> of a directory
This is handled by creating a GIT repository in this directory.
My current implementation needs some more magic by the user to add it to
the index, but I plan to change this to the way that GIT repositories
will be recognized as possible submodules.
> * git-status gets knowledge of how to check for "dirty" submodules
This is on top of my TODO.
> * 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)
it's only update-index that has to know this.
Otherwise it would be implicitly updated and you would never get your
"changed but not updated" status as above.
--
Martin Waitz
Attachment:
signature.asc
Description: Digital signature