Am 06.07.2010 04:36, schrieb Junio C Hamano: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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? -- 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