Duy Nguyen <pclo...@gmail.com> writes:
> On Mon, Apr 20, 2015 at 12:37 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Duy Nguyen <pclo...@gmail.com> writes:
>>
>>> But if you look at it another way, "cd subrepo; git add ." should be
>>> the same as "git add subrepo" ...
>>
>> Once you cd into "subrepo", you are in a different world, a world
>> different from the toplevel project. "git add ." over there should
>> mean "add everything in subproject's working tree to subproject's
>> index", shouldn't it? On the other hand, "git add subrepo" without
>> leavingin the working tree of the superproject is about binding the
>> submodule to the superproject's index.
>>
>> I do not think these two should be the same. Where am I mistaken?
> I think I wrote this sentence and deleted it: I didn't say which way
> was right.
OK.
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
At this point, I think there are two valid things that can happen.
(1) "git add test" inside dir/ectory removes the submodule entry
"dir/ectory" and then adds dir/ectory/test as an individual
entry. After all that is what happens when you replace a file
with a directory, e.g.
>folder && git add folder
rm folder
mkdir folder && >folder/file &&
git -C folder add file
will first register a regular file "folder" and then replace
that with paths underneath.
It would be the same if you did any of the following:
git -C . add dir/ectory/test
git -C dir add ectory/test
git -C dir/ectory add test
(2) "git add test" inside "dir/ectory" would barf, saying
"dir/ectory is supposed to be a submodule and you have to first
remove it". Again, it would be the same if you did so from any
directory with relative paths.
I think (2) is less optimal than (1), but it could be the best we
could do if the submodule infrastracture around .gitmodules and
links to $GIT_DIR/modules/$name may have to get involved in an
operation like this (I didn't check).
In my quick test, it appeared that the behaviour with this patch
applied was neither of the two and instead to silently do nothing,
and if that is the case I think it is quite wrong.
--
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
