On Thu, Oct 27, 2011 at 4:26 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> - 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.. > > Where did you get this idea that submodule is somehow involved in this test? Because "clone2" looks like a submodule (it has ".git" inside with valid HEAD) > I do not see there is any submodules involved; the test uses two > repositories 1 and 2 that appear in the working tree of the main > repository test infrastructure created, but otherwise there is no > sub/super relation among these three, and there are many other tests with > "clone" or "mkdir+init" or "init <newdir>" in the main test repository. If I tweak the test a bit git clone ./. clone2 && GIT_DIR=clone2/.git git add clone2 && GIT_DIR=clone2/.git git add clone2/b then the last command fails with "Path 'clone2/b' is in submodule 'clone2'". So clone2 could be a submodule from that perspective. Doing the the other way around git clone ./. clone2 && GIT_DIR=clone2/.git git add clone2/b && GIT_DIR=clone2/.git git add clone2 "clone2" is not just a normal path. Should we stick with one way only? -- Duy -- 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