On 06/28/2011 02:43 PM, Heiko Voigt wrote:
> 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.
>> 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
--
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