Re: [GSoC 11 submodule] Status update

From: Phil Hord <hordp@cisco.com>
Date: Jun 29, 2011, 21:27 UTC
Message-ID: <4E0B98CA.2050207@cisco.com>
In-Reply-To: <20110628184358.GA3700@book.hvoigt.net>

On 06/28/2011 02:43 PM, Heiko Voigt wrote:

Show 10 quoted lines

> Hi,
>
> On Mon, Jun 27, 2011 at 08:29:18PM -0400, Phil Hord wrote:
>> On 06/27/2011 03:34 PM, Fredrik Gustafsson wrote:
>>> My fourth task (and the main task of this summer) will start on June 27 and
>>> will be to move a submodules .git-dir into the super-projects .git-dir.
>>> Design of this is already done and approved by my mentors.
>> This frightens me a bit, so I read the wiki link about it.  Thanks for
>> explaining where I can find this information.
> I do not know what part of this change frightens you?

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. Maybe this is a design mistake in need of correction. But this change seems both huge and subtle to me. I suspect it will affect many tools which expect the traditional git layout, submodules or not. For example, a third-party tool might seek out the ".git" directory by walking upwards. 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.

    # Find my .git directory
    mygit=${PWD}
    while test -d "${mygit}" && ! test -d "${mygit}/.git" ; do
        mygit=$(dirname "$mygit")
    done

    # Now lets do things with "our" repo
    fetched_sha1=$(cat ${mygit}/FETCH_HEAD)
        .
        .
        .

Granted, script-writers should be using the git plumbing as much as possible to avoid this kind of change. But not everyone can afford to be so conscientious.

Show 16 quoted lines

>> But I'm still confused.
>>
>> If I understand right, the submodule/.git dirs will be moved into the
>> top-level at .git/submodule/.git.  The benefit is supposed to be that
>> this will free up contention on the non-empty submodule directory when
>> the super-project switches branches.
>>
>> In the simple case, git warns "unable to rmdir sub: Directory not
>> empty".  But I can think of other conflicts as well.
>>
>> My question is, how does this proposed change help the situation?
> The proposed change allows us to implement that a submodules directory
> can be completely removed if it was deleted or moved. If we would do
> that currently you would loose all local history of the submodule. I do
> not know what you mean with "conflicts" but this change will help
> submodule towards behaving like they were ordinary directories in git.

I see. By moving the local history out of the way, the submodule directory is free to be changed or removed without harming the local history. That's clever. I think Android's 'repo' tool does something similar.

I think I can answer my other concerns now.  Do these answers sound right?

What happens if the submodule working directory is dirty?  
    Treat it the same as git does for its own working directory.

But what if the submodule working directory is 'clean' after considering
.gitignore?  Do untracked/ignored files also get deleted?
    Treat this the same as git does for its own working directory.

What if a 'git checkout' results in the submodule being removed?
    Remove the entire submodule directory (or just remove tracked files?)

What if a 'git checkout' or 'git merge' results in submodule 'foo' being
added where there is already a file named 'foo'?
    This is a working-directory merge conflict.

Thanks for explaining. I feel better about it all now. I remain concerned about backwards compatibility, but I'm not so worried about conflict-resolution anymore.

Phil