Am 22.04.2015 um 21:58 schrieb Junio C Hamano:
Jens Lehmann <jens.lehm...@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.
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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
