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

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

Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
> Jens Lehmann wrote:
>> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
>>> I find this behavior very inconsistent and annoying.  Why would I want
>>> to commit the submodule change immediately?  Maybe I want to batch it
>>> up with other changes and stage it at a later time.  Why should I have
>>> to unstage them manually now?  I get the other side of the argument:
>>> what if the user commits the .gitmodule change at a different time
>>> from the file change?  In other words, the user should have a way of
>>> saying 'submodule stage' and 'submodule unstage'.
>>
>> Hmm, AFAIK you are the first to bring up such a feature, as in most
>> use cases doing a "git (submodule) add <path>" is expected to stage
>> what you added.
> 
> In my opinion, the 'git submodule add <path>' form is broken, because
> it doesn't relocate the object store of the submodule repository (a
> bug that we need to fix?).

I don't think it is broken. Leaving the .git directory inside the
submodule makes perfect sense for some users (e.g. those which never
intend to push their submodule somewhere else) and doesn't do any
harm unless you want to remove it again in the future (or need to go
back to an older commit where the submodule directory would be in
the way). We have to think very hard before making such changes to
behavior quite some people may rely on, even though I agree some use
cases would profit from it and I think we would do it differently if
we could start over again.

What I think we need rather soonish is "git submodule to-gitfile",
which would help your case too. We should then hint that in those
cases where we refuse to remove a submodule when using "git rm" or
"git submodule deinit" (or the "git mv" for submodules I'm currently
preparing).

>  I always use the 'git submodule add
> <repository> <path>' form, which puts the object store of the
> submodule repository in .git/modules of the parent repository.  This
> form is nothing like 'git add', but more like a 'git clone': arguably,
> 'submodule clone' is a better name for it.

Hmm, it does a clone first and then adds the submodule and the change
to .gitmodules, so I still believe "add" is the correct term for it.
So I really like the color the shed currently has ;-)

> Maybe the WTF "You need to run this command from the toplevel of the
> working tree" needs to be fixed first?  I think it's a matter of a
> simple pushd, popd before the operation and building the correct
> relative path.

I won't object such a change (even though I suspect it'll turn out
more complicated than that).

>  I'm not sure how it'll work with nested submodules
> though.  Then again, I think nested submodules are Wrong; submodules
> are probably not the right tool for the job.

How did you come to that conclusion? Nested submodules make perfect
sense and most people agree that in hindsight --recursive should have
been the default, but again we can't simply change that now.

>>> Now, for the implementation.  Do we have existing infrastructure to
>>> stage a hunk non-interactively?  (The ability to select a hunk to
>>> stage/ unstage programmatically).  If not, it might be quite a
>>> non-trivial thing to write.
>>
>> Have fun when adding two submodules and unstage only one of them
>> later. I think this feature will not work unless you analyze
>> .gitmodules and stage/unstage section-wise.
> 
> Yes, which is why I asked if we have existing infrastructure to make
> this possible.

Not that I know of.