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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 25, 2013, 19:57 UTC
Message-ID: <CALkWK0mAkabTNrBjvv4s_YfTN9j2_Aros=7ZcF7j=KAjJE-yaw@mail.gmail.com>
In-Reply-To: <51509ABA.3040804@web.de>

Jens Lehmann wrote:

Show 14 quoted lines

> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:
>> 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.

Doesn't that sound horribly crippled to you? Is there any advantage to leaving the .git directory inside the submodule? Isn't it always better to relocate it?

Show 5 quoted lines

> 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).

Why a new subcommand? Is there a problem if we do the relocation at the time of 'add'? Will some user expectation break?

Show 9 quoted lines

>>  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 ;-)

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.

Show 7 quoted lines

>> 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'll have to investigate.

Show 7 quoted lines

>>  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.

Okay, I'll do it step-by-step now, with a live example:
1. git clone gh:artagnon/dotfiles, a repository with submodules.
2. git submodule update --init .elisp/auto-complete, a repository that
contains submodules.
3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy,
lib/ert, and lib/popup).  Let's try to initialize them from that
directory ... No! go back to toplevel.
4. Fine.  Where are those submodules?  git submodule status doesn't list them.
5. Okay, let's join the paths by hand and try anyway: git submodule
update --init .elisp/auto-complete/lib/fuzzy.  Did you forget to 'git
add'?  Fantastic.
6. How am I supposed to initialize the darn submodules?!
7. git submodule update --init --recursive .elisp/auto-complete is the
ONLY way (is this even documented anywhere?).  But I just wanted to
initialize one, not all three!
8. Okay, now I want to execute a 'git submodule foreach' on just those
three submodules.  Seems impossible.  Fine, I'll do it myself: for i
in "lib/ert lib/fuzzy lib/popup"; do cd $i; git checkout master; git
reset --hard origin/master; cd ../..; done
9. Whew.  git status.  Changes in auto-complete.  git diff.
"Submodule .elisp/auto-complete contains modified content".  I'm not
allowed to see what changed now?
10. git checkout master; git reset --hard origin/master in
auto-complete.  git status.  How do I stage the changes in just
auto-complete, and not in auto-complete's submodules?  What is going
on, seriously?

This is just two levels of nesting: with more levels of nesting, things only get worse.

Show 6 quoted lines

>>>> 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.
> [...]
> Not that I know of.

Damn. Then, it's certainly not worth the effort. Atleast not now, when there are bigger problems.