Re: Strangeness with git-add and nested repositories
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 29, 2016, 02:51 UTC
- Message-ID
- <xmqqd1p92kll.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <xmqq1t5p7kmp.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 20 quoted lines
> 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.
A cursory bisection suggests that this used to work up to at least v2.7.4; this must be a recent regression.