Re: [PATCH] pathspec: adjust prefixlen after striping trailing slash
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Apr 22, 2015, 22:32 UTC
- Message-ID
- <5538218B.4010400@web.de>
- In-Reply-To
- <xmqq1tjcdjfa.fsf@gitster.dls.corp.google.com>
Am 22.04.2015 um 21:58 schrieb Junio C Hamano:
Show 38 quoted lines
> Jens Lehmann <Jens.Lehmann@web.de> 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 <file>" already does.
Show 7 quoted lines
> 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 ;-)