Re: Why does 'submodule add' stage the relevant portions?

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 26.03.2013 08:57, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> And leaving aside 'add', there are tons of submodules out there
>> which were cloned with older Git who have their .git directory
>> inside the work tree. So a new subcommand (or at least a helper
>> script in contrib) to relocate the .git directory would really help
>> here to migrate these legacy submodules without users having to
>> worry about data loss.
> 
> The question is: after using a "non-relocated submodule" for some
> time, will the user suddenly decide to make it a "relocated submodule"
> one day?

I think quite some users - and definitely myself - will do that as
soon as the full recursive checkout materialized, as that allows to
remove submodules without any directory remaining and even to replace
a submodule with a directory containing other files. And even with
current Git you already get a clean work tree when using "git rm" or
"git submodule deinit" (in current master) on a submodule iff it has
its .git directory stored in the .git directory of the superproject.
It is definitely not a Must Have right now, but I expect it to be
that in the near future.

>>> I meant a variant of add that would clone, but not stage.  I was
>>> arguing for a new subcommand so that I don't have to touch 'submodule
>>> add', not for a rename.
>>
>> Ah, now I get it, I was confused by your reference to 'git submodule
>> add <repository> <path>'. I have to admit I still don't understand
>> the use case you have for adding a submodule without staging it, but
>> maybe it is just too late here.
> 
> I usually reset after running 'git submodule add', because I rarely
> commit the added submodule immediately after adding it.

I'm not sure many submodule users do the same, but even then the
normal ways of unstaging the submodule and .gitmodules should be
sufficient here, no? I'd rather avoid adding a new command to git
submodule for that.