Stefan Beller [off-list ref] writes:
I think (pure speculation), that it the error is in the context
(repository) switching logic.
What happens if you alter the order, i.e. give testfile first and then
the files in the nested
repos?
git add -- file path/to/subdir/file
should do internally IMHO:
git add file
git -C path-to-subdir add file
My undertanding of what _should_ happen in the world order as
currently defined (not necessarily implemented) is:
* "git add -- A B" must work the same way as "git add -- B A" and
"git add -- A; git add -- B"
* "git add -- path/to/subdir/file", when any of path/, path/to/,
path/to/subdir/ is a Git repository that is different from the
current Git repository, must fail.
IOW, if 'path' is a repository (whether it is known as a submodule
to the repository whose working tree contains it, or it is an
untracked directory from the containing repository's point of view),
the index of the containing repository cannot get path/$anything in
it. If you managed to do so, you found a bug [*1*].
path/.git/index can of course have "to/subdir/file" in it, and from
that point of view, "git -C path/to/subdir add file" may one day
become an improved world order. It is just we haven't discussed
that possibility or reached concensus that it is a good idea.
[Footnote]
*1* Of course, some of the bugs in this class may fundamentally be
unfixable and would fall into the same category as "doctor, it
hurts when I do this--don't do it then". For example, you may
treat path/ as the top of the working tree of another repository
whose git-dir is not at path/.git by arranging GIT_WORK_TREE and
GIT_DIR environment variables, but you may do so only when you
actually are accessing the contents of path/ as its own project.
And when you are using the enclosing project (whose .git/ would
sit next to path/), there is no way for "git add path/to/file"
to know that everything under "path/" does not belong to the
current repository and instead it is part of the project rooted
at path/, which is an obvious example of "fundamentally
unfixable" case.
On Thu, Apr 28, 2016 at 9:39 AM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
I think (pure speculation), that it the error is in the context
(repository) switching logic.
What happens if you alter the order, i.e. give testfile first and then
the files in the nested
repos?
git add -- file path/to/subdir/file
should do internally IMHO:
git add file
git -C path-to-subdir add file
My undertanding of what _should_ happen in the world order as
currently defined (not necessarily implemented) is:
* "git add -- A B" must work the same way as "git add -- B A" and
"git add -- A; git add -- B"
I agree.
* "git add -- path/to/subdir/file", when any of path/, path/to/,
path/to/subdir/ is a Git repository that is different from the
current Git repository, must fail.
I agree that this is the current expectation for the world order.
However I would like to propose to change that eventually.
(Once the submodule groups are there and we can treat
submodules as a special form of narrow checkout, we want to
have the feature of adding across submodules and even committing
across submodules/repos, I would think)
IOW, if 'path' is a repository (whether it is known as a submodule
to the repository whose working tree contains it, or it is an
untracked directory from the containing repository's point of view),
the index of the containing repository cannot get path/$anything in
it. If you managed to do so, you found a bug [*1*].
path/.git/index can of course have "to/subdir/file" in it, and from
that point of view, "git -C path/to/subdir add file" may one day
become an improved world order. It is just we haven't discussed
that possibility or reached concensus that it is a good idea.
[Footnote]
*1* Of course, some of the bugs in this class may fundamentally be
unfixable and would fall into the same category as "doctor, it
hurts when I do this--don't do it then". For example, you may
treat path/ as the top of the working tree of another repository
whose git-dir is not at path/.git by arranging GIT_WORK_TREE and
GIT_DIR environment variables, but you may do so only when you
actually are accessing the contents of path/ as its own project.
And when you are using the enclosing project (whose .git/ would
sit next to path/), there is no way for "git add path/to/file"
to know that everything under "path/" does not belong to the
current repository and instead it is part of the project rooted
at path/, which is an obvious example of "fundamentally
unfixable" case.