On Thu, Apr 28, 2016 at 9:39 AM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> 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"
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. > -- 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
