From: Jens Lehmann Date: Sun, 30 Jul 2017 13:43:25 GMT Subject: Re: [PATCH 02/15] submodule: don't use submodule_from_name Message-ID: In-Reply-To: Am 26.07.2017 um 23:06 schrieb Junio C Hamano: > Stefan Beller writes: > >> Rereading the archives, there was quite some discussion on the design >> of these patches, but these lines of code did not get any attention >> >> https://public-inbox.org/git/4CDB3063.5010801@web.de/ >> >> I cc'd Jens in the hope of him having a good memory why he >> wrote the code that way. :) > > Thanks for digging. I wouldn't be surprised if this were a fallback > to help a broken entry in .gitmodules that lack .path variable, but > we shouldn't be sweeping the problem under the rug like that. Sorry to disappoint you ;-) I added this in 7dce19d374 because submodule by path lookup back then only parsed the checked out .gitmodules file. So looking for it by name was a good guess to fetch a new submodule that wasn't present in the current HEAD's .gitmodules, as the path is used as the default name in "git submodule add". The refactoring in 851e18c385 could and should have removed that because since then we use the .gitmodules path to name mapping of the fetched commit. > I wonder if we should barf loudly if there shouldn't be a submodule > at that path, i.e. > > if (!submodule) > die("there is no submodule defined for path '%s'"...); > > though. Not sure if you want to die() or just issue a warning(), but yes.