Am 21.04.2015 um 23:08 schrieb Junio C Hamano:
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).
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'
And I believe that is better than (1), because when removing a
submodule its entry in .gitmodules should also be removed. And
I suspect that adding a file in a submodule to the superproject
will happen more by accident than on purpose (which cannot
happen for files because when you add a new file in a directory
for which git still records a file the latter can be safely
removed as that entry cannot be a file in the worktree anymore).
So I'd vote to have (2) also for "git -C subrepo add .", which
is what started this thread.
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.
Yep.
--
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
