Subject: Re: [PATCH] git submodule: add submodules with git add -f <path>

From: Jens Lehmann <[email-masked]>
Date: Tue, 06 Jul 2010 23:51:14 +0200

Am 06.07.2010 04:36, schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason  <[email-masked]> writes:
> 
>> Resubmitting this as a non-RFC.
> 
> I don't recall any negative nor supporting discussion on this one.  Will
> queue in 'pu' to see if people who do care about submodules complain.

First: I think this patch fixes a bug. Without it "git submodule add"
leaves the work tree in an inconsistent state when either .gitmodules
or the submodule path are ignored: the submodule is checked out and
populated but the path and/or a new .gitmodules file is not added to
the index. And even worse: The advice of the failed "git add" called
from the script that using "-f" might help is misleading here, as
"git submodule add" doesn't know this option.

But while I think adding the --force option to the "git add .gitmodules"
makes perfect sense (as the submodule can't be successfully added until
it is recorded in this file and there is really no point in ignoring
.gitmodules when you decide to use submodules), I'm not so sure about
what to do when the submodule path itself is ignored.

I see two possible behaviors here:

a) We just ignore .gitignore and add the submodule anyways (which is
   what this patch does)

b) We do the same a "git add <ignored file>" does: Print an error
   message, maybe even tell the user to use a - still to be added -
   "--force" (or "-f") option and exit. But without checking out the
   submodule first nor adding or changing .gitmodules.

IMHO b) is more consistent with the current behavior of "git add". And
when you later decide that the submodules files should live in the
superproject and you drop the submodule, the then probably still
present entry in .gitignore might really shoot you in the foot when
you add new files there and they won't show up because they are still
ignored.

What do others think?