Re: [PATCH/WIP 03/11] t5403: avoid doing "git add foo/bar" where foo/.git exists
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Oct 26, 2011, 00:18 UTC
- Message-ID
- <CACsJy8CjJnO6rDVTV1tC9rWXP51LHBtUvNsgVWNfwC+HuNQ-6Q@mail.gmail.com>
- In-Reply-To
- <7vd3dk516p.fsf@alter.siamese.dyndns.org>
2011/10/26 Junio C Hamano <gitster@pobox.com>:
Show 21 quoted lines
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > >> In this case, "foo" is considered a submodule and bar, if added, >> belongs to foo/.git. "git add" should only allow "git add foo" in this >> case, but it passes somehow. > > I do not think the above description is correct. > > The test: > > - populates the current directory; > - makes a clone in ./clone2; > - creates a file clone2/b; > - runs "git add clone2/b" with GIT_DIR set to clone2/.git, without > setting GIT_WORK_TREE nor having core.worktree in clone2/.git/config. > > The last step should add a path "clone2/b" to $GIT_DIR/index (which is > clone2/.git/index in this case). The clone2 is not a submodule to the top > level repository in this case, but even if it were, that would not change > the definition of what the command should do when GIT_DIR is set without > GIT_WORK_TREE nor core.worktree in $GIT_DIR/config.
Now look from "git add" perspective, it does not really care where $GIT_DIR is. It assumes that $(pwd) is working directory's top. So it
- reads content of current directory, it sees "clone2" as a directory - it descends in and see ".git" so "clone2" must be a git link - because clone2 is a separate repository (again $GIT_DIR is not consulted), "b" should be managed by "clone2" - so it stops.
This is the only place I see a submodule (from the first glance) is actually top level repository. Yes I guess we can support this, but it's just too weird to be widely used in pratice..
Show 11 quoted lines
> Running (cd clone2 && git add b) is a _more natural_ thing to do, and it > will result in a path "b" added to the clone2 repository, so that the > result is more useful if you are going to chdir to the repository and keep > working on it. But that does not mean the existing test is incorrect. It > does not just pass somehow but the test passes by design. > > I did not check if later tests look at the contents of commit "new2" to > make sure it contains "clone2/b", but if they do this change should break > such tests. > > So I am puzzled by this change; what is this trying to achieve?
-- Duy