Re: [GSoC 11 submodule] Status update

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 29, 2011, 21:58 UTC
Message-ID: <7vpqlws3jb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E0B98CA.2050207@cisco.com>

Phil Hord <hordp@cisco.com> writes:

> It frightens me because it seems like a fundamental break from the
> current submodule functionality.  Today a submodule exists as a git
> repository with no knowledge that it is a submodule or who its
> super-repository is.

The use of .git that is a text file that records where the real directory is not limited to submodules. Placing that "real directory" somewhere in the .git directory of the superproject is merely a convention.

In other words, it does not change anything fundamental.

> Once it finds it, it will
> (safely, today) assume that is the .git directory relating to its
> files.  After this change, the tool will be broken.

Then it is already broken if it does not pay attention to .git that is not a directory but is a text file that records where the real directory is.

Show 8 quoted lines

> I think I can answer my other concerns now.  Do these answers sound right?
>
> - What happens if the submodule working directory is dirty?  
> - But what if the submodule working directory is 'clean' after considering
>   .gitignore?  Do untracked/ignored files also get deleted?
> - What if a 'git checkout' results in the submodule being removed?
> - What if a 'git checkout' or 'git merge' results in submodule 'foo' being
>   added where there is already a file named 'foo'?

These "different" questions are answered exactly the same way, which is:

>   Treat it the same as git does for its own working directory.

When switching to another branch, a directory that does not exist in the switched-to branch needs to be removed, but we would refrain from "rm -fr" that directory if it has any leftover cruft in it (untracked and unignored files). A submodule directory should behave in the same way.