From: Jens Lehmann Date: Wed, 22 Apr 2015 22:32:43 GMT Subject: Re: [PATCH] pathspec: adjust prefixlen after striping trailing slash Message-ID: <5538218B.4010400@web.de> In-Reply-To: Am 22.04.2015 um 21:58 schrieb Junio C Hamano: > Jens Lehmann writes: > >> Am 21.04.2015 um 23:08 schrieb Junio C Hamano: >> >>> I looked at the test script update. The new test does (I am >>> rephrasing to make it clearer): >>> >>> mkdir -p dir/ectory >>> git init dir/ectory ;# a new directory inside top-level project >>> ( >>> cd dir/ectory && >>> >test && git add test && git commit -m test >>> ) >>> git add dir/ectory >>> >>> to set it up. At this point, the top-level index knows dir/ectory >>> is a submodule. >>> >>> Then the test goes on to turn it a non submodule by >>> >>> mv dir/ectory/.git dir/ectory/dotgit >>> ... >> >> We already do (2) in the cases you describe: >> >> $ git add subrepo/a >> fatal: Pathspec 'subrepo/a' is in submodule 'subrepo' >> $ git -C subrepo add a >> fatal: Pathspec 'a' is in submodule 'subrepo' >> ... >> So I'd vote to have (2) also for "git -C subrepo add .", which >> is what started this thread. > > Does having "mv subrepo/.git subrepo/dotgit" before that "git add" > change your conclusion? > > It is very clear to me that without that "mv" step, (2) is > absolutely the right thing to do, and I agree with you. Huh? Without that mv all files would simply be added to the submodule repo and this would be a non-issue ... what am I missing? I'm just advocating to let "git add ." in a submodule without a .git behave like "git add " already does. > But it is unclear if we should still do (2) when "subrepo/.git" is > no longer there. That has to be done manually and it may be an > indication that is clear enough that the end user wants the > directory to be a normal directory without any submodule involved, > in which case it may match the expectation of the user better to > just nuke the corresponding 160000 entry in the index and replace it > with files in there. I dunno. The user having removed subrepo/.git is just one reason for that. Another is a user adding a file in an unpopulated work tree of a not initialized submodule. I doubt that simply nuking the 160000 entry would be the right thing to do in this case, I expect this to be a pilot error we should barf about ;-)