Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: >> We however *do* know that our working tree is our current directory, so >> it would be wrong to do this: >> >> $ GIT_DIR=clone2/.git git add clone2/2 3; echo $? >> error: 3 is outside our repository, possibly goverened by .git >> 1 >> >> The command should just add clone2/2 and 3 as it was told to. > > I am concerned about clone2/2 in this case, not 3. ... Hmm... If that is the case, I am afraid that I failed to convey my point in the previous message. You are concerned about clone2/2 because you think GIT_DIR=clone2/.git somehow implies that clone2/2 is a file at the toplevel of some repository that should appear at "2" not at "clone2/2" in the index, no? If that is the case, it means you are somehow getting the notion that GIT_WORK_TREE is set to clone2 even though in the example we are discussing it is _not_. Which in turn would mean "3" that is outside of that directory should not even get into the picture. In other words, the wish to register clone2/2 at "2" in the index by stripping clone2/ and the wish to reject "3" as outside because it is impossible to strip clone2/ from it are the same thing. You either should be worrying about _both_ paths, or neither of them. And I am saying that you should be worried about neither of them in this case. GIT_DIR=<some where> without GIT_WORK_TREE set has treated the current directory as the top of the working tree from the beginning of time, and both clone2/2 and 3 _should_ appear in the index in this example, which is $GIT_DIR/index, which happens to be at a confusing location that is clone2/.git/index. > ... I guess we can > check if clone2/.git is the repo we are using. If it is, skip it. -- 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