Re: [RFC] Submodules in GIT
- From
Martin Waitz <tali@admingilde.org>
- Date
- Nov 29, 2006, 16:15 UTC
- Message-ID
- <20061129161543.GG18810@admingilde.org>
- In-Reply-To
- <200611281629.08636.andyparkins@gmail.com>
hoi :)
On Tue, Nov 28, 2006 at 04:29:05PM +0000, Andy Parkins wrote:
Show 11 quoted lines
> 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