Stefan Beller <sbeller@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html